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ABSTRACT 


A  computer  protection  mechanism  is  a  set  of  tools  which  specifies  and 
enforces  the  protection  of  stored  information  from  executing  programs  within 
a  utility.  This  thesis  presents  two  different  protection  mechanisms,  designed 
to  support  protection  controls  for  different  environments  of  a  computer  sys¬ 
tem.  One  mechanism  is  a  formal  mathematical  abstraction  of  a  multi-level 
secure  system,  embodying  concepts  which  are  prevalent  in  military  security. 
The  model  provides  a  representation  for  the  dynamic  characteristics  of  a  sys¬ 
tem,  wherein  simple  and  complex  patterns  of  process  behaviour  can  be 
defined  and  synthesized.  The  model  is  rigorously’  shown  to  preserve  its  pro¬ 
tection  properties  via  mathematical  proofs  of  safety. 

The  second  mechanism  describes  controls  intended  for  a  high-level 
language  environment,  with  examples  and  concepts  being  drawn  from  APL, 
Effects  of  asynchronous  events  are  considered,  and  a  cohesive  mechanism 
which  permits  the  controlled  cooperation  of  mutually  suspicious,  indepen¬ 
dently  encapsulated  subsystems  working  on  the  same  computation  is 
presented.  The  mechanism  is  also  capable  of  handling  sharing,  confinement, 
access  restrictions,  and  other  classes  of  process  intercommunication  prob¬ 
lems. 

Both  the  multi-level  model  of  protection  and  the  high-level  model 
represenf:  practical  controls  which  could  be  realized  efficiently  on  present 
machines.  Providing  such  controls  in  their  respective  environments  not  only 
limits  the  wanton  dissemination  and  alteration  of  information,  but  also 
encourages  users  of  a  computer  utility  to  cooperate  and  share  programs  and 
data  with  one  another  wherever  possible. 
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1.  INTRODUCTION 


"This  secret  is  so  weighty,  ‘twill  require  a  strong  faith  to  conceal  it. " 

"Let  me  have  it;  I  do  not  talk  much." 

—  William  Shakespeare 

"Huck,  have  you  ever  told,  anybody  about  —  that?" 

’"Bout  what?" 

"You  know  what. " 

"Oh  —  course  I  haven't. " 

"Never  a  word?” 

"Never  a  solitary  word,  so  help  me.  What  makes  you  ask?” 

—  Mark  Twain 

When  dealing  with  the  protection  of  objects  in  computer  systems,  paranoia  is 
not  enough.  Information  cannot  be  protected  by  ignoring  loopholes  in  a  system,  nor  by 
proselytizing  for  beliefs  that  no  one  would  subversiveiy  attempt  to  access  the  data. 
Peireuioia  can  be  manifest  at  the  other  end  of  the  spectrum  as  well,  by  including  res¬ 
trictive  but  otherwise  ineffective  regulatory  controls.  Protection  controls  must  be 
founded  upon  well-formulated,  logically  complete  arguments  ■which  assume  the 
viewpoint  that  if  someone  is  permiLled  to  interact  with  an  object,  then  that  interaction 
will  occur.  Otherwise,  the  result  is  tantamount  to  placing  physical  locks  on  only  the 
entrance  doors  to  a  building,  on  the  assumption  that  no  one  would  ever  enter  via  an 
exit  door. 

Privacy  and  protection  are  easily  confused  when  considered  in  conjunction  -with 
computer  systems.  Privacy  is  a  social  and  legal  ethic  which  applies  to  all  individuals. 
It  refers  to  the  right  of  a  person  to  control  the  degree  of  dissemination  of  information 
pertaining  to  that  individual.  The  issue  of  privacy  has  not  resulted  from  the  develop¬ 
ment  of  computers,  but  has  become  exacerbated  by  the  increased  ability  for  sophisti¬ 
cated  machines  to  gather  and  store  vast  amounts  of  readily  usable  data.  Protection, 
on  the  other  hand,  is  a  technical  and  economic  issue.  It  refers  to  the  mechanisms 
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which  can  be  applied  to  computer  heu*dware,  software,  and  data  to  ensure  that  organi¬ 
zational  assets  and  individual  privacy  are  maintained.  Guaranteeing  privacy  therefore 
requires  protection  mechanisms  to  enforce  control.  As  noted  by  Schroeder  [Schr72], 
protection  is  a  means  and  privacy  is  an  end. 

Protection  itself  requires  further  elaboration.  We  use  the  term  to  embody  for¬ 
mal  notions  of  both  security  and  integrity.  The  distinction  between  these  two  concepts 
in  this  thesis  is  significant.  Security  is  the  protection  of  data  against  accidental  or 
malicious  disclosure.  Security  controls  are  therefore  intended  to  prevent  unauthor¬ 
ized  data  flows  associated  with  reading  information.  By  contrast,  integrity  is  the  pro¬ 
tection  of  data  against  accidental  or  malicious  modification,  and  refers  specifically  to 
controls  associated  with  writing  information.  The  need  for  integrity  stems  from  the 
fact  that  the  consideration  of  protection  as  a  coadunate  concept  admits  an  inflexible 
approach  to  the  categorization  of  entities  within  the  system.  For  example,  it  may  well 
be  desirable  to  ha\^  the  source  text  for  a  particular  operating  system  available  to  a 
large  group  of  people,  but  at  the  same  time  severely  limit  those  individuals  who  can 
modify  it.  In  the  sense  that  it  refers  to  the  soundness  or  correctness  of  data,  integrity 
is  a  static  property  in  a  dynamic  system.  Achieving  security  and  integrity  is  the  vehi¬ 
cle  by  which  systemic  protection  is  assured. 

1,1  Protection  Mechanisms 

Protection  mechanisms  may  be  defined  to  be  those  components  of  a  com¬ 
puter  system  which  specify  and  enforce  protection  via  the  control  of  access  of  execut¬ 
ing  programs  to  objects  within  the  system.  This  definition  recognizes  that  programs 
within  the  system  carry  out  the  intentions  of  people  oxitside  the  system.  Thus,  execut¬ 
ing  programs  are  surrogates  for  users,  and  form  the  active  agents  against  which  con¬ 
trols  must  be  directed.  The  definition  is  large  in  scope,  and  includes  mechanisms  rang¬ 
ing  from  primitive  write-permit  rings  on  magnetic  tapes  to  sophisticated  hardware  and 
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software  protection  controls. 

Protection  mechanisms  in  computer  utilities  serve  two  basic  underlying  func¬ 
tions.  The  first  of  these  is  protection  against  accidental  user  error,  such  as  a  typing 
mistake  or  the  inappropriate  application  of  a  program  toward  a  particular  task.  In 
cases  such  as  these,  protection  mechanisms  permit  a  redundant  specification  of 
acceptable  policy  to  be  made  and  enforced.  For  example,  a  write-permit  ring  allows 
the  intention  that  a  magnetic  tape  not  be  modified  in  certain  situations  to  be  enforced 
based  on  auxiliary  specifications  external  to  the  running  program. 

The  second  purpose  of  a  protection  mechanism  is  control  over  user  interaction, 
and  in  particular  malicious  acts.  This  requirement  is  prevalent  in  multi-user  systems 
in  which  the  privacy  rights  of  each  individual  user  must  be  honoured  in  the  face  of 
potential  sheiring  of  some  resources.  Total  user  confinement  is  somewhat  easier  to 
achieve,  and  indeed  is  desirable  in  some  cases,  but  in  general  negates  the  strong 
benefits  of  encouraging  users  to  share  programs  and  other  stored  information  in 
cooperative  efforts. 

The  emphasis  in  this  thesis  is  on  the  design  of  protection  mechanisms  and  their 
relationship  to  their  environmenL  The  control  that  a  mechauiism  may  properly  exert 
depends  largely  on  where  it  is  built  relative  to  the  machine  itself.  Kence,  protection 
mechanisms  must  be  considered  in  close  conjunction  with  their  level  in  the  overall 
computer  utility. 

Figure  1-1  illustrates  this  logical  hierarchy  of  environments  more  precisely. 
The  user  command  interface  handles  initial  secure  log-on  considerations  and  subse¬ 
quent  command  rerouting.  The  log-on  procedure  serves  to  associate  the  user  (or, 
more  precisely,  his  surrogate  processes)  with  information  to  vrhich  he  is  entitled.  The 
proper  identification  of  the  user  is  a  crucial  aspect  of  protection,  although  little  expli¬ 
cit  consideration  is  given  to  it  in  this  work.* 


•  See  Evans,  et  al  [Evan74]  and  Purdy  [?urd74]  for  a  detailed  treatment  of  this  problem. 
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Fii^ure  1-1.  Environment  levels  in  a  computer  utility. 

Most  users  of  computer  utilities  interact  with  a  high-level  programming 
language,  which  may  be  interpretive  or  compiled,  interactive  or  batch.  These 
languages  serve  to  provide  a  programming  environment  which  is  as  independent  of  the 
machine  on  which  they  are  running  as  is  possible. 

The  operating  syslern  acts  as  the  Lnlerface  between  the  machine  itself  and  the 
higher  machine-independent  levels.  It  handles  I/O  operations,  job  dispatch  and 
scheduling,  and  other  system  functions.  It  also  commonly  implements  data  structures 
and  access  operations  for  a  class  of  objects,  such  as  files,  although  such  mechanisms 
may  additionally  appear  at  the  language  leveL  The  security  and  integrity  of  the  user’s 
data  depends  directly  upon  the  proper  functioning  of  these  mechanisms.  For  example, 
a  file  is  immutable  only  if  a  file  system  makes  it  so. 
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The  fined  component  in  the  hierarchy  is  the  physical  machine.  Its  primary  dis¬ 
tinction  is  that  the  machine  is  hardware,  whereas  all  other  levels  are  software.  Protec¬ 
tion  controls  at  this  level  therefore  have  a  substantially  different  view  of  the  computer 
utility  as  a  whole.  Moreover,  the  ramifications  of  a  hardware  malfunction,  and  the  phy¬ 
sical  security  of  the  communication  lines  feeding  the  machine  become  important 
issues  at  this  level. 

\ 

Protection  mechanisms  can  be  implemented  at  any  of  the.se  hierarchical  levels, 
but  may  be  reasonable  only  at  particular  ones.  Mechanisms  applied  at  the  level  of  the 
machine  will  be  able  to  protect  physical  rather  than  logical  entities  in  a  natural  way, 
but  may  be  inappropriate  for  the  forms  of  protection  desirable  in  a  high-level  language. 
From  the  other  viewpoint,  mechanisms  applied  higher  up  wili  be  ineffective  in  govern¬ 
ing  those  levels  beneath  them,  and  are  typically  of  improper  granularity  for  handling 
their  concerns. 


1.2  Objectives 

In  this  thesis.;  two  protection  mechanisms  for  different  environments  are 
developed.  The  goal  is  to  design  useful,  practical  protection  controls,  and  emphasize 
how  these  controls  interact  with  and  fit  into  their  respective  environments.  The  first 
mechanism  is  a  detailed  mathematical  model  which  rigorously  defines  and  provably 
enforces  certain  policies  which  abstract  the  multi-level  concepts  prevalent  in  military 
security.  The  assumption  here  is  that  the  entire  machine  is  to  run  in  multi-level  mode, 
and  hence  the  model  logically  fits  close  to  the  levels  of  the  operating  system  and  the 
physical  machine. 

The  second  mechanism  deals  with  protection  considerations  in  a  dynamic, 
high-level  programming  language  environment.  Focus  is  centred  on  the  language  APL, 
although  the  protection  mechanism  which  is  developed  is  applicable  to  virtually  any 
high-level  environment.  The  mechanism  provides  a  means  to  control  communication 
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and  sharing,  mutually  suspicious  interactions,  confinement,  and  other  problems.  While 
these  controls  could  be  implemented  as  part  of  the  hardware  architecture  (as  demon¬ 
strated  by  Schroeder  [Schr72]  in  the  context  of  Maitics),  we  choose  to  consider  them 
as  high-level  language  controls  independent  of  the  host  machine. 


The  mechanisms  described  are  paper  models  only,  although  much  considera¬ 
tion  to  their  implementation  is  given.  Abstracting  and  specifying  ^systems  in  this  way 
provides  a  formal  framework  for  organizing  and  defining  the  design  and  implementa¬ 
tion  of  a  system,  and  for  gaining  confidence  in  its  ultimate  behaviour.  Without  such 
models,  designers  must  resort  to  intuition  and  nef  hoc  tschnicju.es  for  addressing  crucial 
problems  during  system  development.  In  particular,  models  of  computer  protection 


provide  the  following  salient  advantages; 


1.  Allow  the  concise  representation  of  the  basic  concepts  of  security  and 
integrity  that  are  relevant  to  the  particular  environment  to  be  defined, 

2.  Provide  the  framework  for  rigorously  defining  important  terms  to  be  used 
throughout  the  discussion  of  the  model. 

3.  Permit  a  mathematical  analysis  and  verification  of  protection  policies,  and 
provide  an  eflielenl  iiieouaniaiij.  by  which  changes  to  them  can  be  studied  and 
insight  gained. 

4-.  Facilitate  feasibility  studies  of  the  implementation  of  the  model. 

5.  Allow  a  posts7~iori  validation  or  justification  of  any  implemented  results  to  be 


performed  bj'  direct  comparison  with  the  model. 


With  the  exception  of  the  last  point,  these  key  roles  of  computer  systems  modelling  will 


be  exploited  In  this  work. 
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1.3  Related  Work 

Efforts  to  design  and  build  safe  computer  systems  have  been  underway  for 
more  than  a  decade  now.  Many  disparate  designs  have  been  proposed;  in  some  cases, 
these  have  led  to  the  construction  of  prototypes  and,  in  even  fewer  instances,  to  sys¬ 
tems  that  could  actually  be  put  into  production.  In  order  to  characterize  our  current 
level  of  knowledge,  we  briefly  review  the  approaches  taken  by  others  in  related  areas  of 
computer  protection  research  and  modelling. 

The  work  performed  by  Weissman  [Weis69]  on  the  construction  of  the  ADEPT-50 
time-sharing  system  stands  out  as  one  of  the  first  attempts  to  implement  non-trivial 
software  controls  for  classified  information.  Although  the  system  was  never  certified 
for  operation  as  a  multi-level  secure  system,  its  internal  controls  were  nonetheless 
based  on  a  formal  model  of  military  security.  Weissman’s  system  identified  four 
different  types  of  objects:  users,  terminals,  jobs,  and  files.  Each  object  was  qualified  by 
a  series  of  properties  which  were  sufficient  to  describe  the  structure  of  military  secu¬ 
rity  to  a  reasonable  degree.  Dynamic  Sow  of  information  from  one  file  to  another  one 
of  lower  classification  was  not  prevented,  however.  Moreover,  control  over  integrity 
and  aggregation  of  data  were  provided  only  by  user  vigilance. 

At  the  same  time,  Lampson  [Lamp69b]  presented  an  abstract  framework  which 
could  be  used  to  rigorously  discuss  and  attack  the  problem  of  computer  security.  He 
was  the  first  to  identify  and  describe  the  concept  of  ''subjects”  and  "objects"  as  the 
active  and  passive  entities  in  a  computer  system,  respectively.  He  later  extended  his 
formulation  to  include  the  riolion  of  an  "access  matrix,''  an  abstract  data  structure  for 
organizing  the  control  of  subjects  over  objects  [Lamp?!].  Graham  and  Denning 
[Grah72]  give  a  good  exposition  of  the  model  proposed  by  Lampson,  and  extend  it 
further  by  specifying  both  a  particular  set  of  control  attributes  associated  with  access 
attributes,  and  a  series  of  primitives  to  dynamically  alter  the  entries  in  the  matrix. 
Because  of  the  theoretical  simplicity  of  the  access  matrix  scheme,  and  because  it 
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admits  a  wide  variety  of  implementation  techniques,  it  has  been  used  extensively  in 
many  modelling  and  implementation  efforts  (including  [Bree72,  Bell73b,  Heirr7G, 
Gors78]).  Without  some  additions,  however,  the  access  matrix  model  does  nut  possess 
sufficient  mechanisms  or  rules  to  support  military  security. 

One  further  difficulty  with  access  matrices  is  that,  in  actual  computer  systems, 
the  matrix  would  be  quite  spairse  if  implemented  as  a  two-dimensional  array,  since  typ¬ 
ically  most  subject-object  interactions  are  prohibited.  Consequently,  implementations 
that  maintain  protection  data  tend  to  store  it  as  a  series  of  row  or  column  vectors  of 
varying  lengths.  Storing  a  list  of  objects  end  allowable  access  modes  for  each  subject, 
known  as  a  ’'capability  list,”  was  a  concept  first  explored  by  Dennis  and  Van  Horn 
[DennSS]  in  the  context  of  operating  systems.  CAL/TSS  [Lamp69a],  SUE  [Sevc72],  and 
Multics  [0rga72,  Salt74]  Eire  examples  of  systems  which  make  use  of  capability-based 
access  controls.  Multics  also  uses  the  inverted  "access  control  list"  approach,  where 
stored  with  each  object  is  a  list  of  subjects  that  may  access  it  and  the  access  modes 
allowed  each.  Although  Multics  Vf'as  not  originally  intended  as  an  environment  for 
multi-level  secui'e  systems,  its  architecture  is  both  original  and  highly  instructive. 

The  conceptualization  of  secure  systems  underwent  a  revolutionary  metamor¬ 
phosis  when  Schell  [Sche73]  conceived  an  approach  that  was  based  on  defining  a  small 
subset  of  a  system  to  be  responsible  for  ensuring  overall  protection.  The  work  was 
manifest  after  the  realization  that  the  whole  of  an  operating  system  is  too  large  and 
complex  to  certify,  and  that  only  a  small  portion  of  system  software  actually  need  be 
concerned  with  the  preservation  of  protection.  Schell’s  mechanism  was  called  a  "secu¬ 
rity  kernel,"  and  sparked  the  development  of  a  number  of  seminal  kernel-based  com¬ 
puter  modelling  efforts. 

Bell  and  La  Padula  [Bell73a,  Bell73b,  Bell74]  developed  the  first  demonstrated 
mathematical  model  of  security,  which  was  later  extended  somewhat  to  tailor  it  to  the 
exigencies  of  Multics  [Bell75b].  The  model  was  a  signiucaxiL  advance  in  defining  mill- 
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tary  security  concepts  formally  in  a  way  applicable  to  computer  systems.  It  is  based 
on  finite  state  machines  as  a  formal  approach  to  describing  the  operating  characteris¬ 
tics  of  a  system.  Certain  military-based  security  properties  are  defined,  and  permissi¬ 
ble  subject-object  interactions  which  do  not  violate  these  properties  are  specified  for  a 
sample  system.  The  model  is  basically  a  specialization  of  the  access  matrix  concept  to 

incorporate  military  security  policy.  Four  modes  of  access  were  provided:  execute, 

1 

read-only,  write-only,  and  read-write. 

Since  its  original  conception,  the  Bell  and  La  Padula  model  has  been  modified 
and  reformulated  in  a  number  of  respects  as  it  has  been  applied  to  various  design  and 
implementation  projects.  One  restatement  of  the  model  is  given  by  Feiertag,  et  al 
[Feie77].  They  define  the  model  in  terms  of  subjects,  objects,  read  operations,  and 
modify  operations.  Each  subject  and  object  is  assigned  a  security  level,  and  a  group  of 
five  axioms  which  govern  the  behaviour  of  the  system  is  defined.  The  authors  use  this 
model  as  a  stepping-stone  to  another,  nearly  equivalent  model  that  is  more  amenable 
to  automated  proofs  of  secuiTLy.  Other  designs  and  implenienlalions  of  the  Bell  and  La 
Padula  model  include  the  SIGMA  message  system  used  in  the  Military  Message  Experi¬ 
ment  [Ames78],  the  Secure  Communications  Processor  (SCOMP)  for  the  Hone3nvell 
Level  6  [BonnSQ],  and  the  Kernelized  VM/370  project  [Gol79].  Hinke  and  Schaefer 
[Hink75]  and  Grohn  [Groh78]  provided  specific  interpretations  of  the  model  as  applied 
to  secure  relational  database  systems.  The  former  model  was  specifically  intended  for 
implementation  on  top  of  a  Multics.  file  system. 

At  the  same  time  as  the  Bell  and  La  Padula  model  was  being  developed,  a 
related  modelling  effort  was  being  carried  out  by  Walter,  2t  al  [Walt74a,  W’’alt74b, 
Walt75]  at  Case-Western  Reserve  University,  In  this  model,  the  flow  of  information  was 
defined  in  terms  of  "agents”  and  "repositories."  Information  transfers  from  one  reposi¬ 
tory  to  another  were  initially  investigated  under  purely  static  conditions,  where  neither 
the  creation  nor  the  deletion  of  agents  or  repositories  was  permitted.  Subsequently, 
dynamic  environments  were  considered  in  an  enhanced  model,  in  which  time-variant 
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characteristics  about  the  system  were  represented  by  a  state  substructure. 

The  UCLA  security  kernel  [Pope78,  Pope79,  WalkBO]  and  the  Provably  Secure 
Operating  System  (PSOS)  design  [>5eum77,  Feie79]  represent  two  other  modelling 
efTorts,  which  are  based  on  a  separation  of  enforcement  mechanisms  from  security  pol¬ 
icies.  Both  of  these  systems  employ  capabilities  for  representing  object  attributes.  In 
the  UCLA  implementation,  the  protection  policy  is  embodied  in  an  autonomous  pro¬ 
cess,  called  the  '’policy  manager,"  which  uses  a  set  of  "colours''  to  control  object 
access.  Each  user  and  file  has  an  associated  colour  list;  for  a  user  to  be  able  to  access 
a  file,  his  colour  list  must  cover  that  of  the  file.  Formally,  the  model  appears  consonant 
with  the  requirements  for  military  sccurit}:,  although  it  has  not  been  exploited  for 
such. 

PSOS  and  the  related  Kernelized  Secure  Operating  System  (KSOS)  [KS0S78]  use 
a  formal  specification  language  (SPECIAL)  to  rigorously  define  the  operating  system. 
The  overall  system  is  hierarchically  decomposed  into  smaller  pieces,  each  of  whose 
operation  depends  only  upon  modules  implemented  at  lower  levels.  Each  function 
reference  aind  state  veiriable  is  assigned  a  security  level,  so  that  the  security  level  of 
every  data  item  referenced  in  the  specification  of  a  function  can  be  progreimmaticaily 
compared  to  the  level  of  the  function  reference,  thus  assisting  in  the  automatic 
verification  of  the  system. 

Jones  [Jone76]  promulgated  an  entirely  different  approach  to  synthesizing  com¬ 
puter  security,  using  graphs  known  as  "take-grant"  systems.  Her  original  work  has 
been  described  and  modified  by  others,  including  Snyder  [Snyd77,  Snyd79]  and  Bishop 
[Bish79].  In  a  take-grant  model,  the  protection  state  of  a  system  is  encoded  in  a 
directed  graph  which  represents  the  same  information  as  would  be  found  in  an  access 
matrix.  Nodes  in  the  graph  correspond  to  either  subjects  or  objects,  and  a  directed 
arc  joining  two  nodes  indicates  that  some  interaction  between  the  nodes  is  permissible. 
'The  arc  is  labelled  with  a  set  of  rights  that  the  node  at  the  tsdl  has  to  the  node  at  the 
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head.  Together  with  the  protection  graph,  the  model  includes  a  set  of  rules  for  adding 
and  deleting  both  nodes  and  arcs.  The  model  contains  no  notion  of  security  levels, 
however,  and  is  thus  not  readily  adaptable  to  military  requirements. 

Of  the  aforementioned  modelling  and  implementation  efforts,  almost  all  are 
concerned  exclusively  with  the  improper  disclosure  of  information,  and  neglect  the 
effects  of  the  improper  modification  of  information.  As  mentioned  earlier,  these 
threats  arise  because  there  is  often  data  which  must  be  observable  to  people  at  many 
clearance  levels,  but  should  be  modifiable  only  in  controlled  ways  by  authorized  agents. 
Biba  [Biba77]  was  the  first  to  notice  this  class  of  threat  and  identify  it  as  data  integrity. 
Very  few  models  are  cognizant  of  integrity  issues.  Both  the  KSOS  and  SCOMP  efforts 
are  intended  to  provide  integrity  controls,  but  the  controls  are  of  a  limited  scope;  it  is 
unclear  how  they  will  ultimately  be  used,  and  how  effective  they  will  be.  The  models 
presented  in  this  thesis  treat  integrity  tantamount  to  security.  The  model  of  military 
protection,  which  is  based  in  part  upon  the  Bell  and  La  Padula  model,  also  explicitly 
defines  a  series  of  formal  integrity  controls  for  precluding  this  class  of  protection 
compromise. 

Very  little  work  has  been  done  in  the  area  of  protection  of  high-level  interactive 
environments,  although  the  basic  problem  areas  are  well  understood.  An  earlier  effort 
to  identify  some  of  the  problems  peculiar  to  interactive  systems  is  documented  else¬ 
where  [Gold78b].  The  salient  difficulties  mentioned  include  acquisition  of  control  of 
execution,  modification  and  display  of  programs  and  data,  alteration  of  the  execution 
environment,  and  late  rebinding  of  names. 

Morris  [Morr73]  presented  a  repackaging  of  various  operating  system  security 
concepts  as  they  might  be  applied  to  programming  languages,  although  not  necessarily 
interactive  ones.  His  mechanisms  included  enhanced  scope  rules,  value  protection 
through  object  mappings,  and  type  protection  through  cascadable  object  tags.  The 
dynamic  features  of  the  mechanisms  were  exploited  through  the  use  of  function- 
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producing  functions. 

One  of  the  first  efforts  to  enhance  the  security  of  APL  was  performed  by  Puck¬ 
ett  [Puck74].  He  introduced  the  concept  of  "qualified  names,"  in  recognition  of  the 
fact  that  many  security  loopholes  exist  through  the  ability  to  dynamically  redefine 
objects.  With  Puckett’s  mechanism,  any  name  could  be  internally  qualified  by  the  user 

identification  of  the  author  of  the  reference;  a  name  not  so  qualified  was  not  the  same 

\ 

as  a  name  with  the  user  number  identification,  and  similarly  the  same  name  qualified 
by  two  different  user  numbers  produced  two  distinct  referents.  Effectively,  the  user 
number  became  a  permanent,  invisible  part  of  the  name  (an  implicit  capability),  thus 
making  it  impossible  for  a  user  to  tamper  with  the  object’s  value  or  definition. 

Ryan  [Ryan73]  developed  the  idea  of  security  transformations,  which  could  be 
applied  to  objects  to  modify  their  external  behaviour.  The  "mask"  transformation  • 
which  he  defined  is  similar  in  intent  to  Puckett’s  qualified  names,  and  replaces  the  visi¬ 
ble  identity  of  a  name  with  a  unique,  invisible  homonym.  Two  other  transformations, 
"lock"  and  "seal,"  apply  to  programs  and  affect  their  incidental  characteristics,  such  as 
interruptability  and  display  potential.  The  transformations  can  be  applied  in  any 
order,  and  interact  to  provide  the  desired  level  of  security.  Moreover,  each  transfor¬ 
mation  (or  combination  thereof)  is  invertible  as  long  as  the  object  is  not  instantiated 
by  propagating  it  into  another  workspace. 

Neither  Ryem  nor  Puckett  addressed  the  problem  of  combining  mutually  suspi¬ 
cious  processes  in  the  same  habitat.  Greenberg  [Gren77]  considered  this  problem,  and 
proposed  an  object  called  a  "package"  (not  to  be  confused  with  the  term  as  applied  to  a 
generic  application  package).  A  package  serves  two  related  purposes:  it  binds  objects 
together  so  that  they  can  exist  as  a  single,  encapsulated  unit,  and  it  establishes  a 
separate  context  for  the  objects.  In  both  of  these  objectives,  they  eu-e  similar  to  the 
package  data  type  espoused  by  the  Ada  programming  language  [DoDBOj.  A  package  in 
Greenberg’s  context  interfaces  with  its  environment  by  means  of  uni-  or  bi-directional 
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data  paths  associated  with  the  appropriate  names  vdthin  the  package.  The  mechanism 
handles  combinability  adequately,  but  if  implemented  would  be  awkward  to  use 
because  the  data  paths  must  be  re-established  whenever  the  active  workspace  is 
changed.  In  practice,  this  means  introducing  a  series  of  cover  programs  simply  to 
fulfill  the  requirement  of  having  open  data  channels  to  the  package. 

Work  by  Morrow  [MorrSO]  takes  a  somewhat  different  approach  to  the  security 
problem.  He  loo  uses  a  sharing  path  interface,  but  the  objects  being  shared  are  surro¬ 
gate  functions  located  in  an  autonomous  task,  rather  than  objects  resident  within  a 
packeige  in  the  workspace.  The  task  switching  implied  by  calling  a  surrogate  function 
from  the  active  workspace,  and  the  associated  presentation  of  parameters  to  the  auto¬ 
nomous  task,  is  done  automatically  by  the  interpreter.  As  with  Greenberg’s  approach, 
however,  additional  machinery  is  required  to  ensure  that  the  desired  data  paths  arc 
extant  in  the  workspace. 


1.4  Organizatioii  of  ttie  Thesis 

Conceptually,  the  work  presented  in  this  thesis  is  divided  into  two  parts, 
corresponding  to  the  two  different  protection  mechanisms  developed.  The  first  part 
isolates  issues  of  multi-level  protection,  and  presents  a  model  which  can  be  used  to  for¬ 
mally  analyze  and  implement  the  controls.  The  second  par-l  addresses  high-level 
domain  protection,  developing  a  mechanism  which  captures  the  concepts  that  are 
relevant  for  achieving  complete  control  over  cooperating  processes. 

The  next  chapter  considers  the  problem  of  providing  military  protection  con¬ 
trols  in  a  computer  utihty.  An  abstract  representation  of  processes  capable  of  describ¬ 
ing  restrictions  on  object  mtercommunieation  is  developed.  The  model  embodies  a 
number  of  protection  policies,  which  reflect  the  nature  of  permissible  interactions  in  a 
multi-level  secure  system.  Chapter  3  presents  a  formal  interpretation  of  the  protec¬ 
tion  model,  including  its  policies,  and  establishes  the  theoretical  framework  within 
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which  the  system  can  be  analyzed.  The  correctness  and  completeness  of  the  model  are 
emphasized.  A  valid  insteintiation  of  the  model  is  shown  to  be  any  set  of  primitive 
operations  which  is  defined  in  terms  of  the  model’s  entities,  and  obeys  the  theoretical 
foundations  that  are  developed.  In  Chapter  4,  such  as  set  of  operations  is  presented. 
The  operations  model  the  implementation  of  military  protection  controls  for  an  arbi¬ 
trary  system.  The  formal  behaviour  of  each  primitive  is  analyzed,  eind  proved  to 
preserve  protection  based  on  the  premises  established  in  Chapter  3.  Chapter  5 
addresses  how  the  model  might  fit  into  the  overall  architecture  of  a  system,  and  also 
considers  some  sophisticated  patterns  of  process  behaviour,  including  the  archival  and 
retrieval  of  data  on  a  system. 

Chapter  6  shifts  the  focus  to  high-level  interactive  envir  onments  by  considering 
protection  in  APL.  Changes  in  the  protection  approach  are  identified,  and  a  new  pro¬ 
tection  mechanism  designed  to  cope  with  the  concomitant  problems  is  defined.  The 
mechanism  handies  confinement,  sharing,  and  mutual  suspicion,  as  well  as  other  major 
classes  of  threats.  The  discussion  is  supplemented  b}’-  a  survey  of  existing  protection 
features  in  APL,  which  is  contained  in  the  appendix  to  this  thesis. 

Chapter  7  concludes  the  thesis  with  a  summary  of  the  work  presented,  and  a 
consideration  of  those  issues  which  deserve  further  thought. 


2.  FORMULATION  OF  THE  MULTI-LEVEL  MODEL 


When  you  wish  to  produce  a  result  by  means  of  an  instrument. 

do  not  allow  yourself  to  complicate  it. 

—  Leonardo  da  Vinci 

\ 

A  model  is  an  image  of  realily. 

—  E.S.  Lee 

A  model  of  computer  protection  provides  a  framework  within  which  protection 
problems  can  be  realized  or  defined,  and  dissimilar  mechanisms  can  be  compared.  A 
model  is  a  useful  prerequisite  toward  ensuring  that  a  system  operates  correctly  and  is 
truly  secure.  To  this  end,  the  model  must  demonstrate  by  its  consistency  that  it  can 
be  translated  into  the  design  of  a  secure  computer  system.  The  connection  between 
the  model,  the  design,  and  the  final  implementation  provides  the  groundwork  for  argu¬ 
ing  that  the  system  correctly  meets  the  necessary  requirements.  Such  a  synthesis 
procedure  is  eikin  to  Dijkstra’s  principle  of  levels  of  abstraction  [Dijk6B],  and  indeed  is 
how  most  modern  systems  are  designed  and  built  today. 

In  order  to  be  credible,  the  basic  freimework  within  which  protection  is  con¬ 
sidered  must  be  simple  and  clear.  No  one  will  believe  an  unstructured,  patched  system 
is  secure,  just  as  no  one  will  believe  that  a  formal  proof  is  correct  if  it  is  long,  verbose, 
and  based  on  imprecisely  defined  terms.  Thus,  a  useful  goal  to  keep  in  mind  when  deal¬ 
ing  with  the  area  of  computer  security  is  simplicity. 

The  model  that  has  been  developed  is  a  set-theoretic  mathematiccd  abstraction 
of  a  computer  utility.  Certain  aspects  of  the  model  have  been  influenced  by  earlier 
modelling  efforts,  in  particular  the  work  performed  by  Bell  and  La  Padula  [Bell73a, 
Beil73b,  Bell74-].  To  make  the  present  model  more  useful  for  investigating  the  rules  on 
operation  of  a  secure  computer  system,  a  primary  objective  has  been  to  to  carefully 
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consider  the  characteristics  of  actual  computer  systems  and  utilities  operating  in 
environments  that  are  at  least  to  some  degree  cognizant  of  security  threats.  It  was 
therefore  important  that  a  reasonable  and  flexible  mechanism  to  represent  processes, 
and  their  controlled  interaction  within  a  system,  be  adopted. 

A  particular  design  requirement  was  to  provide  a  "military  time-sharing  system 
operating  in  a  multi-level  security  mode"  [Sche73].  That  is.  "a  mode  of  operation 
under  an  operating  system  ...  which  provides  a  capability  permitting  various  levels  and 
categories  or  compartments  of  material  to  be  concurrently  stored  and  processed  in  an 
automatic  data  processing  system.  In  a  remotely  accessed  resource-sharing  system, 
the  material  can  be  selectively  accessed  and  manipulated  from  variously-controlled 
terminals  by  personnel  having  different  security  clearances  and  access  approvals" 
(DoD  Directive  5200:2B-M).  The  system  must  therefore  be  completely  secure  in  the 
sense  that  it  permits  no  unauthorized  disclosure  or  modification  of  information  —  that 
is.  no  security  or  integrity  compromise. 

The  model  is  composed  primarily  of  active  and  passive  elements,  access  control 
attributes,  a  system  state,  and  interfaces  to  the  environment.  In  the  remainder  of  this 
chapter,  the  model  will  be  described  narratively.  We  shall  also  attempt  to  highlight  the 
inclusions  and  exclusions  of  meaning  that  can  be  correctly  associated  with  the  model 
itself  in  terms  of  its  descriptive  and  adaptive  capabilities  for  representing  a  situation. 
A  more  detailed  mathematical  treatment  of  the  model  is  given  in  Chapter  3. 


2.1  Active  and.  Passive  Elements 

The  notions  of  protection  and  security  compromise  are  relative,  in  the  sense 
that  something  has  to  be  protected  from  sometiiing  else.  Lampson's  pioneering  work 
[Lamp69b]  suggests  the  partitioning  of  the  information  store  of  a  machine  into  two 
instantaneously-disjoint  sets  called  subjects  and  objects.  Other  people  (see,  for  exam¬ 
ple,  [Bell73a,  Bell73b,  Walt74a,  Biba77,  Gors78j)  have  demonstrated  the  practicality  of 
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such  a  division  and  have  employed  similar  schemes. 

Definition.  A  subject  in  5  is  an  active  element  of  a  computer  system,  in  particu¬ 
lar  a  process.  An  object  in  0  is  a  passive  element  which  can  be  manipulated  by  a 
subject. 

Objects,  then,  refer  to  the  passive  portion  of  a  computer  system  that  require  protec¬ 
tion:  data  files,  information  structures,  memory  resources,  and  so  on.  Subjects  are  the 
active  modifying  agents  of  a  system,  against  which  protection  must  be  provided.  They 
proceed  via  references  to  and  in  ter  actions  with  objects,  and  include  entities  such  as 
processes,  procedures,  subroutines,  and  users.  We  are  primarily  concerned  with  the 
management  of  the  objects  to  which  a  subject  has  access. 

No  restriction  is  made  concerning  the  entities  that  may  be  both  subjects  and 
objects:  a  valid  interpretation  of  the  model  in  a  particulsu*  environment  would  have  no 
subjects  or  objects,  some  subjects  and  objects,  or  all  subjects  could  be  objects  (the 
degenerative  case  is  somewhat  trivial  to  provide  protection  for,  however).  The 
interpretation  of  the  model  will  remain  valid  provided  that,  when  an  entity’s  active  or 
passive  role  is  being  considered,  that  entity  be  constrained  by  the  model’s  treatment 
of  subjects  or  objects,  respectively.  Since  only  one  operation  may  be  physically  con¬ 
sidered  at  any  particular  instant  (since  only  one  process  may  be  physically  executing), 
no  ambiguity  exists. 

The  generalization  to  permit  subjects  to  become  objects  is  an  important  one,  as 
it  permits  subroutines  and  subprocesses  to  exist  (as  shown  in  Figure  2-1).  If  an  object 
had  to  remain  passive,  then  a  subject  could  never  invoke  a  subroutine,  for  the  very 
reference  to  an  entity  by  a  subject  would  make  that  entity  an  object  initially. 
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Figure  2-1.  Subjects  interacting  with  objects. 

2.2  Access  Attributes 

A  crucial  concept  in  the  model  is  its  ability  to  deal  with  various  modes  of 
access,  and  to  appropriately  restrict  the  intercommunication  of  subjects  and  objects. 
The  generic  modes  of  access  in  the  model  are  called  the  access  attrib%Ltes  of  the  sys¬ 
tem,  and  are  denoted  by  the  set  A. 

Definition.  An  access  attribute  in  A  is  an  elementary  generic  control  or  authori¬ 
zation  which  specifies  the  semantics  of  how  a  subject  may  interact  with  an  object. 

For  example,- if  a  subject  possesses  access  attribute  "a"  to  object  oi,  then  Si  may 
access  Oj  in  the  manner  described  by  ”a'’.  The  absence  of  access  attribute  "a"  prohi- 
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bits  such  access.  The  access  attributes  used  with  the  model  are  abstracted  directly 
from  the  actual  access  modes  of  computing  systems  (see  Organick  [0rga72]  and  Bell 
and  La  Paduia  [Bell73b]  for  example). 

In  a  complex  computer  system,  the  two  effects  that  accessing  an  object  can 
have  upon  itself  are  the  extraction  of  information  {obsej'ving  the  object)  and  the  inser¬ 
tion  of  information  {modifying  the  object).  Observation,  as  the  name  implies,  refers  to 
the  viewing  of  information  by  a  subject.  Central  in  concept  to  observation  is  the  test¬ 
ing  of  information.  Based  on  this,  we  can  state  that  observation  is  the  testing  of  infor¬ 
mation  which  results  in  a  choice  of  distinct  states  of  the  observing  subject  (and  there¬ 
fore  possibly  distinct  outputs  from  it). 

Modification  may  be  loosely  defined  in  terms  of  observation.  A  subject  modifies 
the  information  content  of  an  object  if  the  object’s  value  is  changed  so  that  a  subse¬ 
quent  observation  by  a  subject  (possibl)'’  different  from  the  modifier)  results  in  a 
different  state  than  did  previous  observations.  (Note  that  this  definition  tells  only  part 
of  the  story,  however,  for  it  does  not  cover  nilpotent  modification  where  the  initial  and 
final  information  are  identical.  This  is  in  some  senses  not  a  modification,  but  may  be 
important  if  there  are  potential  race  conditions  Vvdth  multiple  users  updating  the  same 
objects.) 

There  are  thus  four  general  types  of  access,  each  of  which  makes  sense  under 
the  appropriate  circumstances: 

•  no  observation  and  no  modification  (execute) 

•  observation  and  no  modification  (read) 

•  modification  and  no  observation  (append) 

•  observation  and  modification  (write) 

We  now  consider  the  meaning  and  implications  of  each  of  these  access  attributes. 
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’’Execute'’  access  permits  the  logical  invocation  of  an  object  as  a  program  or 
routine.  This  mode  of  access  is  simply  a  procedure  request  for  service  which  allows  the 
subject  to  trigger  the  executable  object;  a  user  with  only  "execute”  access  cannot  read 
or  write  any  part  of  the  program.  If  the  program  produces  information  as  output,  the 
information  is  fed  back  to  the  user  who  invoked  it  under  system  control.  For  example, 
the  program  can  write  its  results  to  a  file,  and  the  executor  can  read  the  file  to  deter¬ 
mine  the  outcome  of  execution;  alternatively,  a  monitored  pipe  arrangement  [Kern78] 
can  link  the  two  processes.  If  the  information  produced  is  classified  higher  than  the 
security  clearance  of  the  executor,  then  the  system  will  deny  the  user  read  access  to 
the  file  (or  pipe)  where  the  generated  information  is  available. 

’■Read”  access  can  be  considered  as  permission  to  perform  a  pure-read,  in  the 
sense  that  a  user  with  only  "read"  access  to  an  object  cannot  effect  a  change  to  that 
object.  The  access  mode  enables  us  to  model  several  different  classes  of  situations 
which  would  otherwise  be  awkward  to  handle  in  an  abstraction. 

A  file  coiilaining  information  which  can  be  referenced,  but  which  should  not  be 
altered,  will  be  accessed  in  "read”  mode.  An  obidous  example  of  such  information  is 
the  clearance  and  classification  levels  of  the  subjects  and  objects  in  the  system:  in 
order  to  enforce  the  required  security  rules,  this  information  must  be  accessible  (at 
least  at  certain  times)  and  demonstrably  unalterable.  Read-only  access  provides  the 
necessary  combination  of  protection  and  availability. 

A  second  example  concerns  'i.he  handling  of  peripherals  such  as  input  and  out¬ 
put  devices,  and  information  storage  units.  In  particular,  an  input  device  such  as  a 
card  reader,  which  has  no  inherent  content,  could  be  modelled  as  a  read-only  object. 
(Clearly,  the  permission  associated  with  the  subject  responsible  for  actually  putting 
the  data  in  tbs  system  would  have  to  be  somewiiat  different  from  this,  to  enable  the 
other  side  of  the  interface  to  be  completed.)  Similarly,  an  output  device  such  as  a  line 
printer  would  be  modelled  as  append-only,  an  access  level  to  be  discussed  next. 


-  21  - 


Anedogous  to  the  pure-read  access,  we  include  "append"  access,  which  is  a 
pure-write  anywhere  in  a  file,  "Append"  permits  the  limited  alteration  of  an  object  (in 
particular,  it  permits  the  addition  of  information  to  it),  while  preventing  the  extraction 
of  information  from  it.  lienee  granting  someone  "append"  access  to  a  file  does  not  by 
itself  compromise  the  security  of  the  contents  of  the  file. 

As  already  mentioned,  included  within  the  scope  of  "append"  access  is  the  use 
of  an  output  device,  such  as  a  printer,  which  transfers  information  beyond  the  theoreti¬ 
cal  control  of  the  system.  In  doing  so,  we  enter  the  realm  of  physical  security,  and 
assume  that  devices  which  are  in  nonclassified  areas  will  themselves  be  nonclassified. 
This  is  a  sufficient  assumption  to  ensure  no  compromise  occurs,  with  the  provisos  that 
matching  the  classification  of  the  information  output  and  of  the  output  device  is 
sufficient  to  prevent  unauthorized  personnel  from  viewing  restricted  data. 


To  supplement  the  preceding  two  forms  of  access,  the  model  also  supports 
read/write  or,  more  simply,  "write"  access,  "'^rite"  access  encompasses  both  "read" 
and  "append"  permission,  and  therefore  provides  the  access  required  for  a  general 
update  capability.  For  example,  a  monitoring  application  which  referenced  a  particu¬ 
lar  file  and  incremented  certain  resource  counts  in  it  each  interval  would  use  "write" 
access,  as  would  an  application  that  was  concerned  with  editing  a  file.  Master  file 
updates  which  merge  new  transactions  with  old  ones  would  also  use  this  form  of  access 
permission. 


To  summarize,  then,  the  model  includes  the  four  distinct  access  attributes 
"execute",  "read",  "append",  and  "write".  For  convenience,  access  attributes  may  be 
abbreviated  to  "e",  "r",  "a",  and  "w",  respectively.  Note  that  the  true  meaning  of  an 
access  attribute  is  not  actually  constrained  by  its  name,  in  the  sense  that  "write" 
access  includes  "read"  as  well,  whereas  "append"  does  not.  One  must  understand  the 
specific  access  characteristics  of  a  mode  to  select  the  corresponding  access  attribute. 
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2.3  System  State  Concepts 

With  this  basic  information  in  mind,  we  now  describe  the  components  of  the 
state  of  the  system.  The  system  state  is  a  representation  of  the  current  mode  of 
operation  of  the  model,  and  includes  an  access  relationship  between  subjects  and 
objects,  and  an  assignment  of  security  and  integrity  levels  to  both  of  these  classes  of 
entities.  It  contains  all  of  the  information  considered  pertinent'  to  the  preservation  of 
protection  v.dthin  the  system.  The  following  definition  is  introduced. 

Definition.  A  state  q  is  an  ordered  quintuple  of  the  form  {B,  M,  H,  F,  C)  where  B 
is  a  set  indicating  the  current  access  relationships  between  all  subjects  and 
objects.  Mis  an  access  matrix  embodying  the  potentially  permissible  access  rela¬ 
tionships  between  all  subjects  and  objects,  //  is  a  tree-structured  hierarchy  which 
orders  the  objects  in  the  system,  F  is  a  global  set  of  security  levels  for  the  sys¬ 
tem.  and  C  is  a  global  set  of  integrity  levels. 

Each  of  these  state  elements  is  now  described  in  more  detail. 

The  current  access  set  B  is  itself  an  ordered  triple  of  the  form  {S,  0,  A)  where 
iS  is  the  set  of  subjects  in  the  system,  0  is  the  set  of  objeets,  and  A  is  the  set  of  access 
attributes.  B  specifies  which  subjects  can  access  what  objects  in  what  mode  of  opera¬ 
tion.  The  set  describes  all  such  possible  subject-object  interactions  for  the  entire  sys¬ 
tem  in  the  current  state  q. 

The  second  component  of  the  system  state,  M,  is  an  access  matrix  (or  any  other 
suitable  structure)  which  records  the  modes  in  which  each  subject  may  access  each 
object.  M  is  used  by  the  model  to  implement  ”nccd-to-know'’  control  policies,  and  may 
be  envisioned  as  shown  in  Figure  2-2.  In  this  example,  the  access  matrix  indicates  that 
subject  Sj  has  "append"  (a)  access  to  object  Og,  S3  has  both  "read"  (r)  and  "execute" 
(e)  access  to  og,  and  S4  has  "execute"  (e)  access  to  oi.  Blank  entries  in  the  matrix 
imply  a  default  of  null  access,  so  that  no  other  subject-object  interaction  is  permitted. 
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Figiire  2-8.  An  access  matrix. 

Although  this  representation  of  an  access  matrix  is  the  one  used  throughout  the 
development  of  this  model,  it  is  by  no  means  unique  in  its  capabilities  and  other 
eq_uivalent  forms  would  work  just  as  well.  In  particular,  the  Access  Control  List  (ACL) 
scheme  employed  by  Multics  [Salt74]  could  be  used  instead.  An  ACL  essentially 
specifies  which  processes  (the  active  elements  in  Multics)  are  allowed  to  reference  a 
particular  segment  (or  passive  element),  and  under  what  modes  of  operation  the 
access  is  permitted.  (Also  included  in  the  ACL  is  some  ring  bracket  information 
governing  the  rings,  or  hierarchical  compartments,  in  which  the  access  is  permitted. 
The  ring  information  is  of  no  import  to  the  current  discussion.) 
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Access  Control  Lists  are  assigned  on  a  per-segment  basis.  Thus,  the  informa¬ 
tion  contained  in  the  ACL  for  a  particular  object  is  comparable  to  the  column  of  the 
access  matrix  associated  with  that  object.  The  ACL  for  object  02  representing  the  same 
levels  of  access  as  in  the  previous  discussion  is  shown  in  Figure  2-3. 


PROCESS  ACCESS 

IDS  flnRIJUTES  BRACKETS 


It  is  worth  emphasizing  the  pragmatic  difference  between  B  and  M.  The  set  B 
specifies  which  subjects  are  actiLally  allowed  to  communicate  with  which  objects,  and 
how  they  may  do  so.  M  specifies  what  modes  of  access  could  be  extended  to  the 
appropriate  subject-object  pairs,  should  the  access  really  be  required.  In  this  manner. 
M  specifies  need-to-know  access,  which  must  always  be  an  improper  subset  of  the 
access  identified  by  5.  J/is  a  "can”  specification,  while  B  is  "may.” 

The  third  component  of  a  sj^tem  state  within  the  model  is  the  object  hierarchy, 
H.  H  is  the  union  of  a  single  directed,  rooted  tree  structure  and  possible  isolated 
points,  which  in  totality  specify  the  organization  of  objects  within  the  system.  The 
hierarchical  tree  is  specified  so  that  it  prohibits  an  object  from  being  directly  inferior 
to  two  different  objects,  and  so  that  it  forbids  a  ring  of  objects,  each  directly  inferior 
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Figure  2-4«  Example  of  a  hiereiichy  (after  [Neum77]). 
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(or  superior)  to  the  next.  An  example  of  such  a  hierarchy  is  shown  in  Figure  2-4.  Iso¬ 
lated  vertices  correspond  to  those  objects  which  are  inactive  in  a  particular  state  — 
that  is,  not  accessible  by  any  subject  along  any  hierarchical  path.  In  a  Multics  setting, 
the  active  subjects  (those  in  the  tree  portion  of  the  hierarchy)  would  be  the  segments 
in  the  directory  structure,  and  the  terminal  objects  (those  with  no  inferior  nodes) 

would  represent  the  data  segments.  The  hierarchy  is  dynamic,  and  facilities  are  pro- 

\ 

vided  to  permit  the  creation  and  deletion  of  objects  within  it. 

To  simplify  examining  the  progeny  of  each  object,  we  define  ^et(oi)  to  be  the  set 
of  direct  descendants  of  the  object  in  the  hierarchy,  and  to  be  the  ancestor  of 

Oi,  which  is  empty  (^)  if  is  the  root  node  or  not  a  valid  object.  (Note  that  a  primitive 
such  as  ha  is  a  sufficient  tool  to  permit  the  implementation  of  hierarchies  as  a  collec¬ 
tion  of  lists.)  We  also  use  the  notation  ha(oi)  and  hl{oi)  to  denote  the  transitive  closure 
of  the  progeny  and  ancestry  of  o^,  respectively.  The  formal  definition  of  a  hierarchy  is 
now  given. 

Definition.  A  hierarchy  H  is  a.  tree  structure,  possibly  augmented  with  isolated 
points,  such  that  two  vertices  implies  haioi)  haioj)  =  !p  for  all  o^,  Oyeif, 

and  such  that  there  is  no  set  of  objects  of  arbitrary  cardinality  n  where 
O(tinodn)+1  -  ^diOi)  for  any  i, 

Object  control  is  expressed  implicitly  within  the  framework  of  the  hierarchy. 
Specifically,  "write"  access  to  an  object  which  is  the  ancestor  of  Oj  implies  the  capa¬ 
bility  to  alter  the  access  privilege  of  any  subject  with  respect  to  Oj.  The  type  of  control 
thus  generated  is  both  flexible  and  implicit,  lending  itself  easily  to  hierarchically  struc¬ 
tured  file  systems. 

The  fourth  component  of  the  state  of  the  model  is  the  set  F  specifying  the  secu¬ 
rity  levels  of  all  subjects  and  objects  in  the  system.  A  security  Level  is  a  composite 
entity  consisting  of  an  object  classification  or  a  subject  clearance,  and  a  category  set. 
Security  levels  are  designed  to  meet  government  specifications  for  classifying  sensitive 
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data  [Sche73]. 


Definitioo.  A  classification  (or  a  clearance)  is  a  level  ’.vithin  a  set  of  hierarchi¬ 
cally  ordered  seciirity  or  integrity  jurisdictions.  A  category  set  is  a  discrete  set 
of  need-to-know  divisions  or  classes,  which  formally  organizes  the  association  of 
certain  information  with  a  subject  or  object.  A  security  leijel  is  an  ordered  pair  of 
the  form  {classification^  category  set)  or  {clearance,  category  ^sei). 


A  clearance  is  a  property  of  a  subject  which  entitles  it  to  observe  objects  at  or  below  a 
certain  classification.  Security  clearances  and  classifications  are  typically 
"unclassified,'’  '’confidential,"  "secret,"  and  "top  secret,"  and  are  strictly  ordered.  A 
subject  cleared  to  access  "secret"  information  may,  if  it  needs  to,  also  access 
"confidential"  data,  but  may  not  access  "top  secret"  data.  Government  category  sets 
are  usually  "unrestricted,"  "restricted,"  "sensitive,"  and  "crypto.”  Categories  arc  not 
strictly  ordered,  but  are  unordered  collections  compared  via  set  inclusion.  Thus,  a 
subject  with  categories  "unrestricted"  and  "sensitive"  may  be  able  to  reference  an 
object  with  either  or  both  of  "unrestricted"  and  "sensitive,"  but  will  not  be  able  to 
reference  an. object  with  categories  "unrestricted"  and  "restricted." 


The  combination  of  strictly  ordered  classifications  and  unordered  category  sets 
results  in  a  partial  ordering*  of  security  levels;  that  is,  an  ordering  in  which  some  pairs 
of  elements  are  not  comparable. 


Definition.  The  binary  dominance  relation  of  the  partial  ordering  is  represented 
notationally  by  <  (or,  inversely,  by  >),  so  that  is  equivalent  to  stating  that 

A 1  is  dominated  by 


One  security  level  is  dominated  by  another  if  its  classification  is  less  than  or  equal  to 
the  classification  of  the  other,  and  its  category  set  is  included  in  the  other  category 
set.  For  example,  the  level  (UNCLASSIFIED,  \R’S])  is  doniiiiaLed  by  (SECRET,  ^RSCO  but 


♦The  partial  ordering  requires  only  tJiat  (1)  every  level  always  dominates  itself  (reflesivity);  (2)  if 
dominates  and  /.g  dom.iriate.s  £»2,  then  dommates  ^>3  (transitivity^;  and  (3/  it  and  Z.'j  arc  mutually 
dominating,  then  they  are  the  samLC  (antisymmetry). 
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incomparable  to  the  level  (SECRET, 

It  is  easily  checked  that  every  two  security  levels  have  a  least  upper  bound,  or 
join,  which  is  greater  than  or  equal  to  both,  and  less  than  or  equal  to  any  security  level 
that  is  greater  than  or  equal  to  both.  Similarly,  any  pair  of  security  levels  also  has  a 
greatest  lower  bound,  or  meet.  The  set  of  security  levels  therefore  foirris  a  partially 
ordered  lattice.  Figure  2-5  shows  such  a  lattice,  which  is  simply  :^a  lesseracl,  for  the 
tj’picai  government  classifications  and  category  sets.  For  cia.rityi  only  upward  flows  are 
valid  in  the  diagram.  Tnus,  for  example,  transmissions  from  (CONFIDENTIAL,  iRSj)  to 
(SECRET,  fRS])  or  to  (SECRET,  [RSCj)  are  permitted,  whereas  those  from  (CONFIDEN¬ 
TIAL.  |RS0  to  (UNCLASSIHED,  [RS^  or  to  (SECRET.  [R])  are  not. 

Notationaily,  the  (maximum)  security  level  of  a  subject  is  denoted  by  /s(si), 
and  represents  an  ordered  pair  consisting  of  a  clearance  and  a  category  set 
corresponding  to  Similarly,  the  security  level  of  an  object  is  denoted  by 
represents  the  classification  and  category  set  corresponding  to  Oj.  A  further  dynamic 
functional  assignment  to  subjects  identifies  the  current  operating  security  level  of  the 
subject.  The  current  level  of  s^,  denoted  by  /c(si),  allows  a  subject  to  operate  at  a 
level  less  than  its  maximum  security  level.  This  is  valuable  because  it  offers  direct  sup¬ 
port  of  the  "need-to-know"  concept,  and  because,  as  demonstrated  later,  it  makes 
feasible  the  efficient  hnplernentation  of  the  requirement  that  high-level  information  not 
be  put  into  iow-ievel  objects.  The  current  security  level  of  a  subject  must  always  be 
dominated  by  its  maximum  security  level,  that  is,  fci^i)  <  fsi^i)- 

Definition.  The  triple  of  security  level  assignment  functions  (fg,  /c  fc)  is  called 
a  SBcwrity  lf?vel  fxLTLctioTi. 


The  final  component  of  the  system  state  is  G ,  the  embodiment  of  integrity 
classifications  in  the  model.  The  function  G  assigns  to  each  subject  and  object  an 
integrity  level.  An  integrity  level,  like  a  security  level,  consists  of  a  classification  (or  a 
clearance)  and  a  category  set,  which  form  a  partially  ordered  dominance  relation. 
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Figure  2-5.  A  partially  ordered  security  lattice. 
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Typical  integrity  classifications  are  "nonsensitive,"  "sensitive,"  "critical,"  and  "very 
critical."  Analogous  to  the  security  level  function  F,  the  function  G  is  a  triple 
(9s>  9o>  9c)  where  flrs(si)  is  the  maximum  integrity  level  of  a  subject  Si.  go(oj)  is  the 
integrity  level  of  an  object  Oj,  and  gd^i)  is  the  current  operating  level  of  the  active  sub¬ 
ject  Si. 


The  basic  rules  of  the  model  allow  dynamic  alterations  to  the  elements  which 

\ 

comprise  the  system  state.  For  example,  if  a  subject  wishes  to  add  an  object  to  its  por¬ 
tion  of  B  with  some  associated  level  of  permission,  it  simply  issues  a  request  to  the 
primitive  function  that  governs  that  particular  type  of  state  change.  The  algorithm  of 
the  primitive,  which  is  provably  correct,  consults  F,  G,  and  Af  in  determining  whether 
or  not  to  permit  the  state  transition,  and  adds  the  new  triple  to  B  if  the  transition  is 
permitted.  The  model  makes  the  assumption  that  subjects  can  and  will  access  objects 
if  they  are  explicitly  permitted  to  do  so,  so  a  clearly  important  first  step  in  preventing 
security  compromises  is  to  ensure  the  correctness  of  B.  As  shall  be  seen  later,  how¬ 
ever,  the  task  of  detecting  and  preventing  implicit  security  compromises  from  occur¬ 
ring  is  significantly  more  complex. 


2 A  Liputs  and  Outputs  of  the  Model 

Input  and  output  operations  are  a  crucial  aspect  of  secure  computer  systems, 
because  they  are  the  interface  between  two  distinct  security  enforcement  mechan¬ 
isms.  On  one  side  are  the  internal  logical  security  controls  of  a  computer  system  that 
associate  hardware  and  software  security  attributes  with  the  information  in.  the  sys¬ 
tem,  and  on  the  other  side  is  the  physical  security  system  that  employs  barrier  separa¬ 
tion,  people,  paper,  and  document  markings  to  achieve  its  goals.  Clearly,  a  primary 
requirement  for  1/0  in  a  secure  computer  system  is  that  the  security  attributes  of 
information  are  correctly  transferred  as  the  information  itself  moves  between  the 


internal  and  external  environments. 
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In  the  more  abstract  terms  of  our  model,  we  can  envision  the  model  itself  as 
being  a  black  box  with  two  bilateral  channels  to  funnel  the  incoming  and  outgoing  infor¬ 
mation.  identical  in  concept  to  a  sheired  variable  processor  [Lath73].*  Inputs  to  the 
system  are  referred  to  as  requests  and  outputs  as  results  (notationaliy,  and 
respectively). 

Definition.  A  request  in  *  is  an  appeal  for  service  to  the  system  on  behalf  of  a 
subject.  The  semantics  of  the  request  are  defined  by  a  priinitive  function,  or 
execution  routine,  in  the  model.  A  result  in  is  the  formal  response  of  the  sys¬ 
tem  to  a  request  presented  to  it. 


2.4.1  System  Requests.  The  types  of  requests  described  here  represent  one  possible 
approach  to  abstracting  a  secure  computer  system  within  the  framework  of  our  model. 
The  requests  that  are  supported  were  specifically  tailored  to  be  flexible  in  a  general 
sense,  to  practically  demonstrate  the  capabilities  of  the  model  as  applied  to  a  low-level 
environment.  They  are  in  no  way  unique,  and  a  different  environment  with  different 
needs  and  offerings  would  undoubtedly  require  an  alternate  set  of  requests.  As  dis¬ 
cussed  in  Chapter  6,  for  example,  a  high-level  interactive  environment  possesses  very 
different  assumptions  from  that  of  an  operating  system,  resulting  in  a  modified 
approach  to  providing  protection. 

A  given  type  of  request  is  modelled  by  writing  a  supporting  primitive  kernel 
function  for  it,  in  terms  of  the  entities  that  define  the  model.  A  number  of  general 
functions,  which  can  be  grouped  into  four  consolidated  categories,  are  imrriediately 
suggested  by  examining  the  system  state  Q: 

•  functions  to  alter  the  current  access  levels  (B) 

•  functions  to  alter  the  current  access  permission  structure  (Af) 


*  Ihe  model  can  be  viewed,  for  exeimple,  as  an  auxiliary  processor  which  shares  variables  with  the  operating 
sy5t.em  eoid  sits  in  wait  slate  in  anticipation  of  an  incoming  request  for  service. 
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•  functions  to  alter  the  object  hierarchy  {fT) 

•  functions  to  alter  the  security  and  integrity  level  functions  {F  and  G) 

This  list  covers  changes  to  each'  of  the  elements  of  a  system  state.  Assuming  an 
environment  wherein  subjects  Eu-e- surrogates  for  users,  four  corresponding  categories 
of  requests  are  evident: 

1.  Requests  by  a  subject  to  be  granted  (or  to  relinquish)  access  to  an  object  in  a 
particular  mode; 

2.  Requests  by  a  subject  that  another  subject  be  granted  (or  relinquish)  some 
access  attribute  with  respect  to  some  object; 

3.  Requests  by  a  subject  to  create  (or  destroy)  an  object  in  the  system;  and 

4.  Requests  by  a  subject  to  alter  the  security  or  integrity  level  classification  of 
an  object,  or  the  current  security  or  integrity  level  of  a  subject. 

Since  the  systemic  problems  of  security  can  be  dealt  with  one  transaction  at  a 
time  (assuming  proper  cognizance  of  asynchronous  events),  the  primitive  function 
approach  provides  an  adequate,  and  indeed  extremely  flexible  framework  for  isolating 
transactions.. 

When  an  incoming  request  is  encountered,  a  number  of  checks  miist  generally 
be  made  by  the  system  to  ensure  that  fulfilling  the  request  is  both  possible  and  free 
from  potential  security  compromise.  The  details  of  these  checks  are  discussed  for¬ 
mally  in  the  proofs  of  the  kernel  primitives  in  Chapter  4.  It  is,  however,  worthwhile  to 
briefly  consider  their  implications  at  this  point. 

Category  1  requests  cover  extending  or  removing  "read",  ’'write”,  "append”,  or 
"execute"  access  to  an  object.  Perhaps  the  most  obvious  check  associated  with  grant¬ 
ing  access  by  a  subject  to  an  object  is  to  ensure  that  the  subject  making  the  request  is 
allowed  to  access  the  object  in  the  mode  it  is  requesting.  This  is  accomplished  in  an 
efficient  manner  by  checking  the  access  matrix.  For  example,  in  Figure  2-2,  a  request 
by  a  subject  Sg  to  be  granted  "read”  access  to  object  Og  would  be  acceptable  based  on 


-  33  - 


this  criterion,  but  a  request  to  be.  granted  "execute”  access  would  not.  Other  checks 
must  also  be  made  to  ensure  that  dynamic  security  conditions  are  preserved  in  the 
light  of  granting  the  request:  this  is  discussed  in  the  next  chapter. 

Category  2  requests  also  require  that  a  number  of  conditions  be  met  in  order 
for  the  request  to  be  considered  valid.  Suppose  a  request  by  subject  S4  is  received  to 
give  the  "read"  access  attribute  to  subject  sg  with  respect  to  object  03.  A  constraint 
arising  from  possible  implementation  considerations  is  imposed  here.  Since,  in  some 
hierarchical  file  systems,  access  to  an  object  is  controlled  not  only  by  its  position  in 
the  object  hierarchy,  but  also  by  a  permission  list  stored  in  the  object’s  ancestor,  such 
requests  will  require  that  S4  have  "write"  or  "append"  access  to  og's  parent.  If  03  is  the 
root  node,  then  S4  must  be  allowed  to  give  access  permission  to  the  root  object  in  the 
current  state.  Similar  restrictions  apply  to  requests  for  the  removal  of  access  from  an 
object. 

Requests  in  Category  3  cover  the  addition  and  deletion  of  objects  in  the  system. 
To  simplify  the  effect  of  these  operations  on  the  access  matrix  structure  M,  the  primi¬ 
tive  functions  will  assume  that  Af  is  static  in:  size.  (For  a  production  implementation, 
however,  one  might  choose  to  dynamically  alter  the  size  of  M,  to  avoid  the  possibility  of 
exhausting  all  available  slots.)  Then,  creating  a  new  object  results  in  the  activation  of 
an  unused  object  index.  This  approach  further  avoids  complications  arising  from  hav¬ 
ing  to  dynamically  alter  the  domains  of  the  classification  functions  F  and  G. 

Creating  a  new  object  involves  the  specification  of  where  in  the  hierarchy  the 
object  is  to  be  placed.  It  might  initially  appear  as  if,  from  the  protection  point  of  view, 
such  a  choice  were  arbitrary,  and  had  no  associated  pragmatic  constraints.  However,  a 
number  of  hierarchical  file  systems  (Multics  [Salt74]  and  UNIX  [Ritc78]  among  them) 
treat  locator  directories  as  data  objects,  albeit  somewhat  special  ones.  This  is  in  part 
motivated  by  the  fact  that,  like  data  objects,  directories  possess  sensitive  information 
which  requires  protection.  The  protection  of  data  is  of  precisely  the  same  nature  as 
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the  protection  of  system  directories,  so  treating  directories  as  objects  permits  the 
security  issue  to  be  addressed  in  a  uniform  manner. 

A.n  implication  of  this  is  that  directories  may  have  classifications  associated 
with  them,  which  is  certadnly  useful  because  they  contain  important  information  about 
inferior  objects.  However,  this  could  lead  to  the  situation  illustrated  in  Figure  2-6, 
where  an  unclassified  subject  would  have  to  observe  the  secret  object  0i  (actually  a 
directory  segment)  in  order  to  access  the  unclassified  target  object  Og.  Permitting  this 
would  clearly  constitute  the  potential  for  a  security  compromise. 


UnCLBSSIFIEJ) 


Figure  2-6.  Security  levels  of  a  directory  chain  required  to  access  an  object. 
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To  preclude  such  a  security  threat,  the  creation  of  an  object  will  require  that 
its  security  level  dominate  that  of  its  parent.  (Note  that  if  two  levels  have  the  same 
security  level,  this  requirement  is  immediately  met.)  Furthermore,  the  dual  integrity 
aspect  will  require  that  the  integrity  level  of  an  object  be  dominated  by  that  of  its 
parent.  The  following  definition  is  introduced  to  express  these  concepts  more  pre¬ 
cisely. 

\ 

Definition.  A  state  q  =  (B,  M,  H,  F,  G)  is  said  to  be  compatible*  if  and  only  if 
/o(o)  <  ha{o)jn  andpo(o)  >  h^io)  jfi  for  all  ocO  and  each  }m.‘ 

That  is,  a  state  is  compatible  if  and  only  if  the  security  levels  along  any  path  from  the 
root  are  monotonically  non-decreasing,  and  the  integrity  levels  are  monotonically  non¬ 
increasing. 

An  additional  constraint  pertaining  to  the  creation  of  a  new  object  is  similar  to 
the  one  applied  to  reqTiests  in  Category  2,  and  is  included  here  for  completeness. 
Adding  an  object  below  a  particular  entity  in  the  hierarchy  may,  in  some  systems, 
require  updating  a  pointer  to  the  new^  object  in  the  object’s  parents  Thus,  in  addition  to 
forcing  compatibility,  creation  will  ensure  that  the  active  subject  has  "write'’  or 
"append"  access  to  the  parent  of  the  object. 

Object  deletion  is  supported  in  two  basic  forms,  for  convenience.  One  form 
deletes  a  single  object  from  the  hierarchy,  appropriately  shifting  upward  all  objects 
inferior  to  it.  The  other  form  discards  the  inferior  objects  as  well;  that  is.  it  deletes  all 
objects  at  or  below'^  a  particular  point  in  the  hierarchy.  Both  forms  require  the  check 
that  the  process  attempting  the  delete  operation  has  "write"  access  to  the  parent  of 
the  most  superior  object  being  deleted. 


•  The  concept  of  compatibiiity  (although  not  so  named)  was  initially  proposed  by  Walter,  et  cU  in  [W'ait74a]. 
No  consideration  of  integrity  implications  was  given  at  the  time. 
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The  filial  calegory  of  requests.  Category  4,  pertains  to  alterations  of  the  secu¬ 
rity  and  integrity  level  functions.  These  involve  some  fairly  complex  pragmatic  checks, 
to  ensure  the  continued  dominance  of  certain  levels  over  others.  For  example,  chang¬ 
ing  the  current  security  or  integrity  level  of  a  subject  requires  checking  that  the 
subject’s  maximum  operating  level  dominates  the  new  level.  Changing  the  security 

level  of  an  object  involves  checking  that  the  requesting  subject’s  current  security  level 

\ 

dominates  the  new  level,  which  in  turn  dominates  the  object’s  security  level.  To 
preserve  the  hierarchical  compatibility  initially  guaranteed  by  object  creation,  the 
primitive  must  further  ensure  that  the  new  level  dominates  that  of  the  object’s  supe¬ 
rior,  and  that  the  level  of  each  inferior  object  dominates  that  of  the  new  level.  Addi¬ 
tional  checks  must  also  be  performed  to  ensure  that  no  accidental  leakage  of  informa¬ 
tion  from  one  level  to  a  higher  one  can  occur,  a  topic  to  be  discussed  more  fully  when 
protection  is  addressed. 


2.4.2  System  Results.  The  outputs  of  the  model  are  its  formal  responses  to  a  request. 
There  are  four  different  responses  possible,  represented  collectively  by  the  set  H*. 


The  two  most  basic  decisions  which  the  system  must  be  able  to  make  are 
"valid"  and  "invalid".  The  former  means  the  request  was  acceptable,  both  semantically 
amd  pragmatically,  and  the  latter  means  it  was  not.  In  addition,  we  specify  two  more 
decisions,  "error"  and  "illegal",  to  denote  unusual  situations  in  which  no  action  could 
be  taken.  "Error"  indicates  that  the  decision-making  machinery  in  the  model  is  con¬ 
fused.  It  results  when  two  or  more  primitives  are  simultaneously  applicable  to  the 
same  request.  When  such  an  ambiguity  exists,  it  is  due  to  an  error  in  the  conditions 
associated  with  one  or  more  primitives.  Since  it  is  not  definitely  known  which  of  the 
applicable  rules  to  apply,  the  system  camnot  consider  the  request  any  further.  Gen¬ 
erally,  the  "error"  decision  would  be  used  for  debugging  purposes  during  the  initial 
stages  of  checkout.  However,  the  mechanism  could  be  of  value  in  later  stages  should  a 
cheuage  in  the  rules  governing  the  primitives  ever  be  desired. 
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The  result  '’illegal'’  is  used  to  indicate  that  the  request  is  not  semantically 
recognizable.  In  the  model  itself,  this  simply  means  that  no  primitive  is  applicable  to 
the  request  being  made.  For  example,  a  request  to  provide  a  nonexistent  form  of 
access  to  a  subject,  or  to  extend  access  to  an  entity  which  does  not  exist,  elicits  a 
response  of  '’illegal". 

Table  2-1  summarizes  the  four  different  types  of  resists  ^by  showing  the  condi¬ 
tions  under  which  each  occurs. 

TABLE  2-1.  Results  of  the  model. 


Request 

Number  of  Applicable 

Appropriate? 

Primitives 

0 

1 

>1 

YES 

illegal 

valid 

error 

NO 

illegal 

invalid 

error 

2.5  Security  and  Integrity  Conditions 

With  the  establishment  of  specific  access  attributes  and  reqijests,  the  condi¬ 
tions  of  security  and  integrity  can  now  be  discussed  in  more  detail.  The  underlying 
goal  of  the  model  is  to  ensure  that  a  protection  compromise  is  not  allowed  to  occur 
within  it.  By  the  term  "protection  compromise,"  we  mean  the  intuitive  notion  that 
information  is  somehow  disclosed  or  altered  in  an  unauthorized  manner.  This  section 
introduces  the  conditions  that  must  be  satisfied  at  all  times  in  order  to  prevent  a 
security-breaching  information  transfer  from  occurring.  The  concepts  are  presented 
informally  but  with  justification;  formal  mathematical  descriptions  of  the  protection 
policies  are  given  in  Chapter  3. 
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In  considering  the  operation  of  a  computer  system,  two  distinct  classes  of  pro¬ 
tection  policies,  mandatory  and  discretionary,  present  themselves.  A  mandatory,  or 
non-discretionary  policy  refers  to  a  protection  policy  which  is  unchangeable  and.  once 
applicable  to  an  entity  within  the  system,  is  unfalteringly  satisfied  for  all  states  of  the 
system  as  long  as  the  conditions  of  its  application  continue  to  apply.  The  system  must 

therefore  automatically  enforce  a  mandatory  policy.  Policies  addressing  the  objective 

\ 

leakage  of  information  are  thus  of  a  mandatory  nature.  By  contrast,  a  discretionai'y 
policy  is  one  in  which  the  protection  policy  may  be  modified  by  the  user,  even  during 
the  same  instantiation  of  an  entity.  The  decision  to  extend  access  of  a  database  to  a 
user  is  of  a  discretionary  nature,  if  both  the  user  and  the  database  have  compatible 
clearances  and  category  sets. 

The  protection  mechanisms  within  the  model  are  based  on  permission  rather 
than  exclusion  of  access.  This  principle  means  that  the  default  situation  is  lack  of 
access,  and  the  protection  scheme  identifies  conditions  under  which  access  is  permit¬ 
ted.  The  alternative,  in  which  mechanisms  attempt  to  identify  conditions  under  which 
access  should  be  refused,  seems  to  present  the  wrong  basis  for  the  design  of  a  secure 
computer  system.  A  conservative  design  must  be  based  on  arguments  dictating  why 
objects  should  be  accessible  (need-to-know),  rather  than  why  they  should  not:  in  a 
large  system,  it  is  inevitable  that  some  objects  mil  be  inadequately  considered,  and  a 
default  of  lack  of  permission  is  more  fail-safe.  Further,  a  design  or  implementation 
mistake  in  a  mechanism  whose  purpose  it  is  to  give  explicit  permission  tends  to  fail  by 
refusing  permission,  a  safe  situation  and  one  which  will  be  quickly  detected  eind 
reported.  A  design  or  implementation  mistake  in  a  mechanism  which  looks  for  reasons 
to  exclude  access  tends  to  fail  by  not  excluding  access,  a  failure  which  can  be 
dangerous  and  go  unnoticed.  After  all,  subjects  tend  not  to  complain  about  access 
which  they  already  possess  eind  know  about,  whether  they  are  supposed  to  have  it  or 


not. 
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2.5.1  Mandatory  Protection  Policy.  Meindatory  policies  in  the  model  guard  against 
security  and  integrity  breaches  by  internally  blocking  unauthorized  access  attempts 
based  on  subject  and  object  attributes.  Policies  necessary  to  do  this  under  the  condi¬ 
tions  of  both  static  and  dynamic  protection  are  now  developed. 

2.5.1. 1  Static  Protection.  Data  is  protected  from  direct  unauthorized  observation  or 
modification  by  means  of  static  protection  policies.  To  ensure  static  security  is 
preserved,  it  is  necessary  to  prevent  a  subject  with  a  given  clearance  level  and  a  given 
set  of  categories  from  having  read  access  to  any  object  possessing  a  classification 
which  exceeds  the  clearance  of  the  subject,  or  a  category  set  which  includes  an  ele¬ 
ment  that  the  subject  does  not  possess.  More  concisely,  static  security  stipulates  that 
if  (s.  0.  obs)  is  a  current  access,  where  obs  is  either  "read''  or  ''write'',  then  the  max¬ 
imum  security  level  of  s  must  dominate  the  level  of  o.  Another  way  of  viewing  this  is 
that  there  is  no  reading  upward  in  security  level. 

The  static  security  condition  is,  in  effect,  a  strict  interpretation  of  typical  secu¬ 
rity  regulations  for  classified  documents,  with  one  salient  difference.  In  a  document 
system,  "access”  to  a  document  implies  the  ability  to  extract  information  from  it  — 
that  is,  to  observe  it.  In  the  model,  the  possibility  of  providing  access  to  a  document 
without  permitting  observation  exists,  in  the  form  of  the  "append"  attribute.  Thus,  the 
static  security-preserving  condition  was  specifically  applied  only  to  those  attributes 
that  entail  observation  (viz.  "read"  and  "write"). 

The  dual  of  static  security,  static  integrity,  protects  data  from  direct 
modification  in  an  analogous  fashion.  The  integrity  condition  requires  that  if 
(s,  o,  mod)  is  a  current  access,  where  mod  is  either  "append"  or  "write",  then  the  max¬ 
imum  security  le%'el  of  s  must  dominate  the  level  of  o.  That  is,  there  is  no  writing 
upward  in  integrity  level. 
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Static  security  and  integrity  together  define  static  protectixin.  Note  that  this 
pertains  to  the  immediate  ability  to  manipulate  information  in  an  unauthorized 
manner  —  it  does  not  involve  potential  or  possible  consummation  of  security  breaching 
acts.  Indirect  security  compromises  involve  broadening  the  scope  of  our  protection 
policies,  to  consider  what  might  happen  over  several  state  changes  in  the  model.  These 
policies  are  discussed  next. 

\ 

2.5.1.2  Dynamic  Protection.  In  certain  cases,  a  combination  of  two  or  more  accesses, 
none  of  which  in  isolation  constitutes  a  security  compromise,  can  lead  to  a  potential 
for  later  compromise.  Moreover,  such  situations  involve  a  loss  of  control  on  the  part  of 
the  security  system,  whereby  it  becomes  possible  to  have  high  classification  material 
added  to  a  low  classification  file  or  repository  without  the  appropriate  changes  being 
made  to  security  classification  lists.  To  avoid  the  potential  for  a  protection  threat  in 
these  situations,  and  to  ensure  that  control  over  protection  is  maintained,  policies 
which  describe  and  prohibit  such  compromises  are  required. 

Potential  compromise  is  a  meaningful  and  important  concept  w'ithin  the  realm 
of  computer  systems,  but  has  no  direct  analogy  outside  it.  If  an  individual  has  a  clear¬ 
ance  of  ’’secret,”  he  may  read  documents  classified  at  that  level,  by  he  may  also  write 
documents  classified  at  the  lower  level  of  ’'confidential.”  By  virtue  of  his  clearance 
level,  he  is  trusted  not  to  include  secret  information  in  the  confidential  document,  in 
the  same  sense  that  he  is  trusted  not  to  disclose  secret  information  in  any  other  unau¬ 
thorized  manner.  Although  the  potential  for  encroachment  exists  here,  it  takes  on  a 
much  more  subjective  and  open  appearance  than  when  the  ideas  are  translated  into 
the  domain  of  a  computer  system.  When  the  individual  is  using  a  computer,  the  situa¬ 
tion  is  markedly  different  because  programs  that  he  may  have  little  knowledge  of  will 
be  executing  on  his  behalf.  For  example,  he  may  invoke  a  compiler  to  translate  a  pro¬ 
gram  into  machine  language.  One  could  assume  that  the  compiler  performs  the 
desired  language  translation  and  nothing  else,  but  in  building  a  secure  computer 
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system  we  cannot  afford  to  assume  that  a  given  program  behaves  properly  with  respect 
to  security  and  integrity  requirements.  Indeed,  the  contrapositive  viewpoint  must  be 
adopted:  unless  a  program  is  proven  to  behave  in  a  certain  Tashion  as  described  by  a 
mathematical  model  or  other  formal  specific ation,  no  statement  about  its  behaviour 
can  be  made,  and  we  must  make  the  assumption  that  the  program  attempts  to  violate 

security  regulations  (possibly  through  a  Trojan  Horse,  a  trap  door,  or  other  subversive 

\ 

mechanism).  For  example,  the  compiler  mentioned  above  may,  in  addition  to  doing 
the  translation,  proceed  to  copy  some  of  the  user’s  secret  information  (perhaps  includ¬ 
ing  the  source  program  itself)  into  an  unclassified  file.  At  a  later  time,  an  unclassified 
user  may  read  the  unclassified  file,  thus  gaining  access  to  the  secret  information.  The 
seeuaiiu  is  lliuslrated  in  Figui'e  2-7.  The  compiler  had  access  to  this  information  origi¬ 
nally  only  because  it  was  running  as  a  procedure  on  behalf  of  a  user  who  was  cleared  to 
that  level;  it  acted  subversively  because  the  author  of  the  compiler  wanted  it  to. 


A  simple  but  realistic  way  of  viewing  this  problem  is  to  consider  information  as 
objects  which,  are  moved  around  in  repositories  or  containers.  (Walter,  et  al  [Walt74b] 
and  Bonyun  [BonyTS]  explore  this  approach  in  more  detail.)  Associated  with  each  repo¬ 
sitory  is  a  security  classification  which  reflects  the  relative  sensitivity  of  the  informa¬ 
tion  stored  within  it.  Hence,  a  malicious  program  might  pass  secret  information  along 
by  putting  it  into  an  information  container  labelled  at  a  lower  level  than  the  informa¬ 
tion  itself. 

The  problem  of  dynamic  security  can  now  be  restated  in  terms  of  the  model. 
The  potential  for  a  security  breach  exists  if  a  subject  simultaneously  has  observe 
access  to  a  high  security  object  and  modify  access  into  a  lower  security  one.  In  the 
most  reduced  form,  the  compromise  is  effected  if  three  events  occur: 

1.  The  subject  reads  data  from  the  high  security  object. 

2.  This  data  is  subsequently  -written  into  a  lower  security  object,  either  inadver¬ 
tently  or  deliberately. 


-  42  - 


SECRET  FILE 


UnCLRSSIFIED  FILE 


Figure  2-7.  Potential  dynamic  security  compromise. 

3.  Another  subject,  cleared  to  the  lower  level,  gains  access  to  the  object  and 
reads  the  high  level  data  contained  in  it. 

At  least  two  ways  of  preventing  this  situation  from  occurring  are  known.  The 
first  is  to  detect  the  writing  of  high  level  data  into  a  lower  level  object,  and  accordingly 
upgrade  the  security  level  of  the  object.  This  tecimique,  which  involves  the  transfer¬ 
ring  of  levels,  is  known  as  establishing  a  "high-water  mark."  The  security  level  of  an 
object  then  becomes  a  dynamic  function  of  the  levels  of  all  subjects  which  ever  wrote 
data  into  it.  An  approach  similar  to  this  was  used  by  Weissman  in  the  ADEPT-50 
[Wies69].  To  handle  potential  integrity  compromises,  the  scheme  requires  a  dual  low- 
water  mark  policy  for  integrity  levels  [Biba77].  While  this  approach  does  keep  the 
system’s  beliefs  about  clearances  and  classifications  in  agreement  with  the  actual 
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clearances  and  classifications,  it  has  the  serious  drawback  of  monotonically  upgrading 
security  levels  and  downgrading  integrity  levels.  The  results  can  be  somewhat  unna¬ 
tural,  and  in  practice  tend  to  lead  to  the  overciassifieation  of  data.  Also,  while  the 
approach  does  eradicate  potential  threats,  it  has  the  undesirable  effect  of  making  it 
extremely  difficult  to  recover  from  improper  observe  access  to  an  object,  without 
introducing  additional  controls  in  the  system. 

\ 

The  second  technique  involves  denying  the  w^riting  of  high  level  data  into  a  lower 
level  object.  This  strategy  greatly  simplifies  the  detection  and  restraint  of  improper 
write  access,  for  the  price  of  making  some  objects  write-protected  to  a  particular  sub¬ 
ject.  Because  it  is  more  conservative  in  this  respect,  and  because  it  is  easily  extensi¬ 
ble,  this  technique  was  chosen  as  the  basis  for  providing  dynamic  protection  in  the 
model. 

The  dynamic  security  property  in  the  model  requires  that  if,  in  any  state  of  the 
model,  a  subject  has  simultaneous  observe  access  to  object  and  modify  access  to 
object  Oj  (that  is,  (s,  o^,  obs)  e  B  and  (s,  Op  mod)  €  5),  then  the  security  level  of 
must  be  dominated  by  the  security  level  of  Op  Equivalently,  there  is  no  writing  down¬ 
ward  in  security  level. 

This  property  clearly  disallows  the  situation  pictured  in  Figure  2-7.  Moreover,  it 
implies  that  if  a  subject  has  simultaneous  "write"  access  to  more  than  one  object,  then 
the  security  levels  of  all  such  objects  must  be  the  same.  This  follows  from  the  stipula¬ 
tion  that  the  levels  of  any  two  objects  to  which  "write"  is  permitted  must  be  mutually 
dominating,  since  "write"  access  involves  both  observation  and  modification.  Hence,  by 
induction  over  all  objects,  there  can  be  only  one  level  at  which  "write"  access  is  permit¬ 
ted. 

Dynamic  integrity  is  again  the  analog  of  dynamic  security,  and  states  that  if 
(s,  Oi,  obs)  £  B  and  (s,  Op  mod)  £  B,  then  the  integrity  level  of  oy  must  be  dominated  by 
the  integrity  level  of  op  That  is,  there  is  no  reading  downward  in  integrity  level. 
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Observing  both  the  static  and  dynamic  security  properties  results  in  a  natural 
ordering  of  the  security  levels  of  all  objects  accessible  by  a  particular  subject.  The 
ordering  is  based  on  the  relative  levels  of  access  among  the  vi.sibie  objects.  Using  bold 
subscripts  to  represent  access  modes  extant  for  a  particular  object,  we  have: 

/o(ow)  <  /o(o*) 

=  fo{OjJ) 

A  similar  ordering  is  evident  when  both  static  and  dynamic  integrity  constraints  are 
observed: 

ffe(Oir)  <  S'o(Or) 

9oioiJ  =  goiojj 

9o{ow)  > 

Figure  2-8  shows  this  ordering  diagrammalically. 

The  embodiment  of  static  and  dynamic  security  and  integrity  policies  is  eluci¬ 
dated  in  Table  2-2.  It  can  be  seen  from  the  table  that  the  security  and  integrity  poli¬ 
cies  are  not  easily  combined  for  a  given  type  of  access,  since  a  variety  of  different  lev¬ 
els  is  always  involved.  The  table  can  be  simplified  by  recalling  that,  even  if  a  subject 
has  ''write”  access  to  more  than  one  object,  the  level  at  which  "write”  is  permissible 
must  be  unique.  We  refer  to  this  level  as  the  subject’s  current  security  level,  /c-  The 
current  integrity  level,  gc,,  is  similarly  defined.  Specifying  and  in  this  manner 
simplifies  the  verification  that  a  particular  access  is  acceptable:  need-to-know  is 
checked  by  consulting  the  access  matrix  M,  and  the  object’s  security  and  integrity  lev¬ 
els  are  checked  against  the  subject’s  current  operating  levels.  The  table  can  therefore 
be  simplified  by  redefining  the  dynamic  protection  properties  in  terms  of /c  and  In 
particular,  we  have: 


/c(s)  <  /o(oa) 

fc{s)  =  /o(Ow) 

/c(s)  >  /o(Or) 


9ci.s)  <  go(Or) 

gc(^)  =  go(Ow) 

gc(s)  >  9o(o^) 
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Figure  2-8.  Security  and  integrity  level  ordering. 
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TABLE  2-2.  Security  and  integrity  policies. 


Class 

Access  Mode 

Head 

Write 

Append 

Security 

fAs)>  fo(Or) 

/s(s)  =  /o(Ow) 

fo(Ow)  <  foioj 

Integrity 

j7o(Ow)  <  go(Or) 

9s(s)=  go(ow) 

gs(sj>go(oj 

TABLE  2-3.  Simplified  security  and  integrity  policies. 


Class 

Access  Mode 

Head 

Write 

Append 

Security 

fc(^)  >  fo(o) 

feis)  =  /o(o) 

/e(s)  <  /a(o) 

Integrity 

gc(s)  <  go(o) 

gds)  -  gdo) 

9c(s)  >  9o(o) 

-  47  - 


These  follow  directly  from  the  definitions  of  and  The  consolidated  security  and 
integrity  policies  which  meike  use  of  this  result  are  presented  in  Table  2-3.  The  access 
mode  subscripts  on  the  object  security  and  integrity  level  functions  have  been 
dropped,  as  there  is  no  longer  any  ambiguity  without  them. 

The  dynamic  protection  policies  described  clearly  prevent  any  compromise 
akin  to  the  one  detailed  in  the  example  at  the  beginning  of  this  section.  The  same 
mechanisms  also  avert  other  typical  situations  which  we  would  like  to  avoid.  For  exam¬ 
ple,  suppose  a  subject  can  read  information  from  a  card  reader  and  print  mforrnation 
on  a  printer.  Then  dynamic  protection  guarantees  that  information  of  a  classification 
higher  than  that  which  the  printer  should  handle  will  not  be  printed  by  it,  even  if  the 
card  reader  is  sufficiently  cleared  to  handle  the  information. 

2.5.2  Discretionary  Protection  Policy.  The  preceding  sections  discussed  mandatory 
policies  in  the  model.  The  enforcement  of  clearance  levels  is  typically  mandated  by 
executive  order,  and  an  individual  is  not  free  to  exercise  his  own  judgement  in  this 
matter.  Similarly,  the  enforcement  of  category  sets  is  mandatory.  Catering  to  these 
two  restrictions  led  to  the  non-discretionary  static  and  dynamic  protection  strategy. 

There  is,  however,  an  additional  aspect  of  protection  that  is  often  desirable,  and 
providing  it  encourages  and  supports  the  need-to-know  concept.  Discretionary  protec¬ 
tion  allows  an  individual  to  extend  access  rights  over  an  object  to  another  individual, 
based  on  the  former's  own  discretion,  and  subject  to  the  constraints  dictated  by  man¬ 
datory  policy.  That  is,  if  both  mandatory  policy  and  need-to-know'  w’-ould  permit  a  par¬ 
ticular  access,  then  access  may  be  extended  according  to  the  user’s  discretion.  More 
specifically,  disoretionary  security  and  integrity  requires  that  if  x  is  any  mode  of 
access  and  (s^,  Oj,  x)  €  B.  then  x  <£  il/y. 
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Although  discretionary  policy  is  not  strictly  necessary,  supporting  it  brings  the 
model  closer  to  reeility  without  violating  any  protection  principles.  Moreover,  the 
absence  of  such  a  mechanism  could  lead  to  the  routine  aquisition  of  exaggerated 
need-to-know  status  levels,  because  of  the  inconvenience  that  would  be  associated  with 
incrementally  adjusting  them. 


2.6  The  Undecidability  of  Protection 

^^^e  notion  of  protection  is,  in  practice,  somewhat  nebulous,  because  complete 
protection  as  such  does  not  exist.  Protection  comes  in  degrees,  and  any  protection 
mechanism  which  is  to  perform  satisfactorily  should  attempt  to  provide  not  perfect 
protection,  but  enough  to  make  it  infeasible  (in  terms  of  cost,  time,  risk,  and  so  on)  for 
that  particular  configuration  to  be  compromised.  Notice  that  we  are  specific  about 
what  it  is  we  are  trying  to  protect  —  the  requirements  and  protection  thresholds  for 
one  environment  may  be  very  different  from  those  of  aiiother.  In  fact,  we  csui  state  as 
a  theorem  that  the  secure  behaviour  of  a  protection  mechanism  in  the  arbitrary  case 
is  undecidable.*  By  ’’secure,”  it  is  here  meant  that  the  protection  mechanism  can 
prevent  a  subject  from  aquiring  a  particular  access  right  to  an  object.  The  result  is 
mainly  of  theoretical  interest,  because  computer  modelling  efforts  typically  deal  with 
restricted,  or  even  individual  cases.  However,  the  theorem  can  provide  us  with  a  for¬ 
mal  basis  for  imposing  certain  restrictions  on  a  model. 

We  begin  by  isomorphically  relating  the  protection  mechanism  under  scrutiny 
to  a  Turing  machine.  If  we  let  the  notion  of  a  security  violation  correspond  to  the  Tur¬ 
ing  machine’s  entering  its  final  state  qj,  then  we  will  have  demonstrated  that  the  issue 
of  safety  is  recursively  unsolvable  for  qf. 


*  Harrison,  ei  al  [Harr76]  have  shown  that,  in  restricted  cases,  the  problem  is  formally  decidable. 
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Let 

T  =  {K,  E,  r.  d,  go.  F) 

be  a  uni-directional  Turing  machine,*  and  let  the  generic  access  attributes  A  of  the 
protection  mechanism  be  in  /T  x  F  u  (next,  last],  where  "next"  and  ’last’  are  special 
attributes  to  be  defined  later. 

\ 

At  any  particular  instant,  the  Turing  machine  will  have  scanned  some  leftmost 
group  of  cells  and  deposited  a  nonblank  character  from  F  -  ]  in  each.  Let  k 

represent  the  index  of  the  rightmost  cell:  scanned.  Thus  there  is  an  infinity  of 
unscanned  cells  to  the  right  of  the  fc**  cell  (see  Figure  2-9). 


SCflmED  CELLS 


Figure  2-9.  Modelling  a  sequence  of  states  using  a  Turing  machine. 

Consider  a  protection  mechanism  that  is  composed  of  a  finite  set  of  generic 
access  attributes,  and  a  finite  set  of  primitive  functions.  Each  primitive  consists  of  a 
monolithic  sequence  of  operations <  and  an  optional  prefix  of  conditional  tests  typically 
based  on  generic  access  attributes.  The  conditioned  tests  select  whether  or  not  the 
operations  of  the  primitive  eu*e  actually  to  be  performed.  If  the  tests  evaluate  to  true, 
then  all  of  the  operations  are  executed  in  a  non-interruptable  sequence;  otherwise, 
none  of  the  operations  is  executed. 


♦  Sec.  for  example.  Hoperoft  and  IJllman  for  a  rigorous  treatment  of  Turing  machines. 
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The  protection  mechanism  also  contains  a  finite  set  of  active  subjects  (or 

processes),  iS".  Subject  is  represented  by  cell  i  on  the  tape.  The  access 

attributes  associated  with  each  subject  correspond  to  the  permissible  states  and  tape 

symbols  of  the  machine.  For  example,  if  subject  possesses  access  attribute  "x”,  then 

cell  i  of  the  tape  will  contain  "x”.  Further,  we  assign  access  attribute  q  to  denote  the 

present  state,  so  that  if  the  machine  is  currently  scanning  cell  j,  we  give  generic 

\ 

right  q  to  itself.  Note  that  since  K  and  F  are  disjoint,  this  representation  is  not  ambi¬ 
guous. 

An  additionad  access  attribute,  "last**,  is  used  to  mark  the  last  subject  ever 
scanned,  s^.  possesses  access  attribute  "last'’,  to  indicate  that  (which  Sjj.  would 
normally  immediately  precede)  has  not  yet  been  created. 

Without  loss  of  generality,  we  can  consider  the  set  5  to  be  a  well-founded  par¬ 
tial  ordering  over  the  binary  relation  <  if,  for  xj,  sj  €  S ,  Si  <  Sj-  iff  i<j.  The  special  case 
where  i  and  j  represent  adjacent  ceils  on  the  tape  will  be  denoted  by  giving  access 
attribute  "next”  to  s^.  (This  is  done  only  for  convenience  and  consistency  in  formulat¬ 
ing  the  conditional  tests  appearing  in  the  primitives.) 

Let  the  moves  of  the  Turing  machine  be  specified  by  a  function  6  from  /T  x  f  to 
K  X  (T  ~  \B  ])  X  \L ,  Rl.  5  is  a  quintuple  of  the  form  {qi.Xj,  q^,  Xi,  Dm)  meaning  that 
5(qi,  wYj)  =  5(gjk,  Xi,  Dm)r  where  and  g*  states,  Xj  and  Xi  are  tape  symbols,  and 
Dm  is  the  direction,  for  m-L  or  /?. 

The  moves  of  the  Turing  machine  are  now  more  formaily  represented  in  terms 
of  our  protection  mechanism.  A  move  left  is  characterized  by  6(q,X)  =  6(q\  F,  L). 
Suppose  s  is  the  cell  currently  being  scanned.  The  current  state  is  g,  and  this  is 
represented  by  a  g  in  ceil  s.  s  also  contains  the  tape  symbol  X,  Avhich  the  move 
transmutes  into  the  nonblank  symbol  F.  The  final  state  after  the  move  is  q’ ,  with  the 
tape  head  scanning  cell  s'.  The  move  is  equivalent  to  the  fallowing: 
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procedure  move^lefi  {s,  5* ) 
begin 

if  [iiextj  £  T{s\  s)  and  \q]  €  T{s,  s  )  and  IX]  £  T{s.  s)  then 
begin 

T{s,  s)  ^  (T(s.  s)-[X,  q\)^ 

T(s\  s')  ^  T{s\  s')  u  \q'l 

end 

end  move_ie/i 


In  the  case  of  a  move  right,  where  6(q,  X)  =  6{q',  Y,  B).  two  alternatives  exist: 
one  to  handle  the  situation  where  the  next  cell  is  out  of  the  range  of  those  previously 
scanned,  and  one  to  handle  the  simpler  situation  where  the  cell  has  already  been 
visited.  The  latter  case,  move^right,  is  essentially  symmetric  to  the  7nove_left  com¬ 
mand.  If  the  cell  is  of!  the  end  of  the  tape  however,  the  move  is  more  complex: 

procedure  7aove_Tight_jnew{s,  s' ) 
begin 

if  flastj  €.  T{s,  s)  and  fgl  €  T(s.  s)  and  €  ^(s,  s)  then 
begin 

T(s,  s)  ^  (T(s,  s)  -  Hast,  q,  X])  u \Y] 

S  sj\s'] 

T(s,  s')  <-  T{s,  s')  u  fnextj 
T{s'.  s')  <-  T{s'.  s')  u  ^last,  q'.  i?  | 

end 

end  Tnove^Tight^Tievj 

Suppose  we  begin  without  having  scanned  any  cells,  and  with  a  single  subject  si 
in  the  leftmost  cell.  Si  has  access  attributes  go,  B,  and  "last"  to  itself,  to  demonstrate 
this  position.  We  now  prove  two  obvious  lemmas  relating  to  our  Turing  machine 
configuration. 


Lemma  2.1.  (a)  No  matter  how  many  additional  cells  are  traversed,  the  tape  will 
always  have  at  most  one  access  attribute  that  corresponds  to  a  state  in  K.  (b)  No 
matter  how  many  additional  cells  are  traversed,  no  cell  can  have  more  than  one  access 
attribute  that  corresponds  to  a  tape  symbol  in  T. 
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Proof.  The  proofs  follow  directly  from  our  setup  and  from  the  move  commands  wc 
have  defined.  Initially,  we  begin  with  only  one  state  on  the  tape,  go-  of  the  three 

move  commands  must  be  used  to  alter  the  machine  state  and  the  symbols  oa  Lae  tape. 
However,  each  move  command  deletes  a  state  known  by  the  prefix  conditions  of  the 
command  to  exist.  The  body  of  each  command  also  adds  exactly  one  state.  Hence  the 
machine  is  single-state  preserving  throughout. 

\ 

The  proof  of  part  (b)  is  analogous,  after  noting  that  the  initial  configuration  of 
the  Turing  machine  provides  for  only  one  symbol  on  the  tape,  namely  B.  !j 

Lemma  2.2.  In  each  and  every  configuration  Q{q,  (F  -  [B])*,  k)  of  the  protection 
mechanism  derivable  from  the  initial  configuration,  there  is  at  most  one  move  com¬ 
mand  applicable  to  get  from  a  particular  configuration  to  its  successor. 

Proof.  It  is  easy  to  see  that  if  any  move  command  can  be  applied  to  get  from 
configuration  Q  to  Q',  then  only  one  can  since  the  prefix  conditions  of  each  command 
are  mutually  exclusive.  They  are  not  collectively  exhaustive,  however,  for  there  is  no 
move  left  command  to  handle  the  case  where  the  current  cell  being  scanned  is  Sj.  Q 

We  are  now  in  a  position  to  state  the  following  theorem. 

llieorem  2.1.  It  is  undecidable  whether  an  arbitrary  configuration  of  an  arbitrary  pro¬ 
tection  mechanism  is  secure  for  an  arbitrary  access  attribute. 

Proof,  It  is  clear  that  there  is  only  one  finite,  sequence  of  moves  Qo  Qn  that  derives  a 
particular  set  of  configurations,  based  on  the  results  of  Lemmas  2.1  and  2.2.-  The  pro¬ 
tection  mechanism  therefore  exactly  simulates  the  behaviour  of  a  Turing  machine.  If 
the  Turing  machine  enters  its  final  state  g^,  then  the  protection  mechanism  can  "leak" 
the  access  attribute  assigned  to  gy;  otherwise,  the  protection  mechanism  is  secure  for 
gy.  However,  since  it  is  undecidable  if  the  Turing  machine  will  eventually  halt  by  reach¬ 
ing  state  gy,  it  is  clearly  undecidable  if  the  protection  mechanism  is  safe  for  gy.  D 
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Two  comments  on  this  result  are  in  order.  First,  although  it  has  been  stated 
that  simplicity  is  an  admirable  goal  in  the  face  of  credibility,  it  is  recognized  that  the 
goal  is  not  always  achievable.  Protection  mechanisms  can  be  modelled  as  functions, 
and  since  there  are  arbitrarily  complex  computable  functions,  there  must  be  particu¬ 
lar  configurations  in  which  protection  is  decidable  but  arbitrarily  complex.  It  is  antici¬ 
pated  that  such  environments  are  either  reducible  in  difficulty  or  else  impractical, 

\ 

based  on  the  fact  there  are  no  known  instances  of  them. 

The  second  point  also  follows  from  the  theorem,  and  is  intuitively  obvious.  To  a 
large  degree,  the  correctness  of  a  model  of  computer  security  rests  upon  the  mechan¬ 
isms  which  extend  the  access  attributes  permitting  subject-object  interactions.  Frivo¬ 
lously  propagating  the  ability  to  extend  access  makes  it  significantly  more  complex 
and  costly  to  prove  that  extant  authorizations  are  continually  consistent  with  owners’ 
intentions.  Indeed,  permitting  the  dynamic  propagation  of  such  access  can  require  the 
introduction  of  complex  monitors,  or  detailed  flow  control  policies  to  ensure  that 
classified  data  is  not  leaked  to  the  wrong  channels  [Lamp73,  Denn79].  The  safety  prob¬ 
lem,  which  seeks  answers  to  questions  of  the  form  "Can  the  programs  of  user  X  gain  a 
particular  access  right  to  object  17",  remains  answerable  relatively  efficiently  if  rea¬ 
sonable  constraints  are  imposed  on  the  operation  of  the  system.  An  interesting 
instance  of  this  is  systems  conforming  to  the  "take-grant”  model  [Jone76,  Snyd77, 
Bish79],  where  it  has  been  shown  (in  [Jone78])  that  there  is  a  linear  algorithm  for 
deciding  the  safety  question.  As  Theorem  2-1  demonstrates,  however,  where  the  access 
rights  of  each  subject  are  not  well  understood,  the  safety  question  becomes  either 
undecidabie  or  else  prohibitively  expensive. 

2.7  Summary 

A  model  of  a  protected  computer  system  has  been  presented.  In  designing 
the  model,  rigorous  attempts  were  made  to  make  it  as  practical  and  as  realistic  as 
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possible,  by  drawing  on  the  issues  and  problems  of  actual  multi-user  computer  sys¬ 
tems.  Where  a  number  of  design  choices  were  evident,  the  reasons  for  advocating  a 
particular  one  were  discussed.  The  resultant  abstraction  is  suitable  as  the  basis  for 
considering  a  number  of  protection  modelling  problems  in  the  area  of  multi-level 
secure  systems. 

The  model  represents  active  elements  (such  as  programs)  as  subjects,  and  pas¬ 
sive  elements  (such  as  data)  as  objects.  The  objects  within  the  system  are  ordered  in  a 
hierarchy,  vmich  at  all  times  obeys  a  number  of  constraints  required  to  preserve  pro¬ 
tection. 


The  concept  of  security  amd  integrity  levels  was  defined,  and  applied  to  each 
subject  and  object.  Three  different  classes  of  protection  policies  —  static,  dynamic, 
and  discretionary  —  were  presented.  One  data  structure,  B ,  within  the  model  defines 
the  permissible  interactions  between  subjects  and  objects,  and  is  used  to  implement 
static  and  dynamic  protection.  An  access  matrix  structure,  M.  specifies  potential 
interactions,  and  is  used  to  implement  discretionary  protection.  This  information, 
along  with  the  object  hierarchy  and  the  security  and  integrity  level  functions,  was 
coalesced  into  the  concept  of  a  system  state,  which  represents  the  system's  instan¬ 
taneous  operating  characteristics. 


As  an  adjunct  to  the  development  of  the  model,  we  presented  the  interesting 
result  that  the  preserv'ation  of  protection  in  the  general,  arbitrary  case  is  undecidabie. 
The  impact  of  this  theoretical  result  is  straightforward;  one  cannot  hope  to  find  an 
algorithm  which  can  certify  the  safety  of  an  arbitrary  protection  mechanism.  PIow- 
ever,  safety  in  specific  cases  is  decidable,  so  the  result  should  not  dampen  our  hopes  of 
proving  a  specific  protection  mechanism  to  be  protection-preserving. 


3.  MATHEMATICAL  FOUNDATIONS 


"How  many  days  are  there  in  a  year?” 
"Three  hundred  and  sixty-five,  "  said  Alice. 
"And  how  many  birthdays  have  you?" 

"One.” 


"And.  if  you  take  one  from  three  hundred  and  sixty-five, 

what  remains?" 

J.  fOi  iULL§  UKUj-t  ^KjU  \tKA*  J  L-AjO^  J  GvCf  /  k/ J  C  \J  U>  4  ki  •. 

Humpty  Dum.pty  looked  doubtful. 
"I'd  rather  see  that  done  on  paper, "  he  said. 

—  Lewis  Cttx  xoll 


Having  established  the  details  of  the  model  and  the  jastificalions  for  adopLiug 
certain  viewpoints  in  Chapter  2,  the  model  of  protection  can  be  discussed  on  a  more 
formal  level.  The  purpose  of  this  chapter  is  to  provide  the  theoretical  framework 
within  which  protection  can  be  analyzed,  and  unsafe  situations  identified.  Some  addi¬ 
tional  terms  are  defined,  and  the  underlying  protection  properties  of  the  model  are 
rigorously  formalized.  The  chapter  concludes  with  a  series  of  theorems  and  corollaries 
relating  to  the  preservation  of  the  protection  properties  of  the  model.  The  reader  is 
assumed  to  have  a  certain  degree  of  familiarity  with  the  concepts  inv’^olved  from  the 
preceding  chapter,  so  definitions  and  properties  are  presented  in  concise  form  and 
with  minimal  argument. 


3.1  Elements  of  the  Model 

Table  3-1  lists  the  elements  of  the  model  and  briefly  describes  the  semantics 
of  each.  Most  of  the  symbols  have  already  been  introduced  during  the  foregoing 
development  and  discussion  of  the  model.  The  notation  given  here  will  be  used  to 
describe  the  system  throughout  the  remainder  of  the  work  on  the  multi-level  protec¬ 
tion  model. 
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TABLE  3-1.  Elements  of  the  model. 


Symbol 

Semantics 

5 

subjects  (active,  information  processing  elements  of  a  com- 
outine  system,  such  as  procrams  or  tasks  in  execution) 

0 

objects  (passive,  information  repository  elements  of  a  com- 

\  , 

puting  system,  such  as  data,  messages,  files,  or  peripheral 
devices) 

K 

partially-ordered  set  of  security  classifications  and 
categories 

L 

partially-ordered  set  of  integrity  classifications  and 
categories 

A 

access  attributes  ('’execute”,”read",  '’append",  "write'') 

/?« 

input  recuests 

R* 

output  results  ("valid",  "invalid",  "error",  "illegal") 

B 

current  access  set  of  subjects  over  objects 

M 

access  matrices  denoting  the  access  attributes  of  subjects 
over  objects 

H 

hierarchically-organized  tree  structure  ordering  the  objects 
in  the  system 

F 

security  level  descriptor  functions  (  f ) 

G 

integrity  level  descriptor  functions  (.7*1  7ni  7r.) 

Q 

states  of  the  system,  in  terms  of  B,  M,.  H,  and  G. 

T 

complete  set  of  discrete  times 

X 

T 

ordered  sequence  of  requests  from  i?®  based  on  T 

Y 

T 

ordered  sequence  of  results  from  based  on  T 

Z 

ordered  sequence  of  states  from  Q'^  based  on  T 

hAoi) 

descendants  of  o<  in  the  hierarchy  H 

hAoA 

ancestor  of  o<  in  the  hierai’chy  H 

set  of  primitive  kernel  request  functions 

relation  defining-  a  sequence  of  configurations  over  ^ 

E 

system  embodying  extant  properties  of  the  model  as  well  as 
the  history  of  all  previous  configurations 
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3.2  System  Definitions 

This  section  gives  a  number  of  general  definitions  relating  to  the  d3niamics  of 
the  system.  The  definitions  pertain  to  abstract  entities  which  are  necessary  to 
describe  the  behaviour  of  the  system  at  a  particular  instant,  and  build  on  the  earlier 
definitions  of  the  state  and  its  components. 

\ 

Definition.  A  primitive  function  ^  is  a  function  from  x  Q  to  R^  x  Q  such 
that: 

Therefore,  q  h  g’  and  the  two  states  may  be  identical  if  the  primitive  resulted  in 
no  net  state  change.  A  primitive  function  is  said  to  preserve  a  particular  pro¬ 
perty  (for  example,  static  protection),  whenever  q'  possesses  the  property  if  q 
does. 

Definition.  A  configuration  is  a  representation  of  a  state  transi¬ 

tion  from  time  i  — 1  to  time  i  if  tcT  and  Zt-i  zt.  A  sequence  of  configurations 
K(^)  c.  X  xY  X  Z  X  Z  is  a  series  of  actions  in  discrete  time  on  the  set  of  primitive 
functions  is  a  relation  over 

Definition.  A  system,  is  denoted  by  Y.{R^ ,  where  7(v)  uniquely 

defines  the  history  of  the  system  from  an  initial  state  zq. 


3.3  Protection  Properties 

The  definitions  which  follow  are  a  formalization  of  the  concepts  of  static, 
dynamic,  eind  discretionary  (need-to-know)  protection,  introduced  in  Chapter  2.  The 
formal  definitions  are  required  in  the  specification  and  proof  of  the  protection 


theorems  in  the  next  section. 
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3.3.1  Static  Protection. 

Definition.  A  state  q  ■=  {B  ,M  >,H  ,F  ,G)  obeys  static  security  if  Eind  only  if: 

(s.o, obs)€5  =>  fs{s)>  fo{o) 
for  all  scS*.  o€0. 

Definition.  A  state  q  =  {B  ,M,H,F ,  G)  obeys  static  integrity  if  and  only  if: 

(y.o.iaod)€j9  ^  gs{s)>go(o) 
for  all  s€.S ,  o€.0 . 

Definition.  A  state  is  statically  protected  if  it  satisfies  both  the  static  security 
and  the  static  integrity  properties. 

3.3.2  Dynamic  Protection. 

Definition.  A  state  q  ,  M\  H^F  ,G)  obeys  dynamic  security  if  and  only  if: 


s,0i,mod)e5  and  (s. oy. obs) /o(oi)  >/o(o,) 


for  all  s€5,  o^.o^gO. 


Definition.  A  state  q  —  {B,M,H,F,G)  obeys  dynamic  integrity  if  and  only  if: 


for  ail  s€.S ,  Oi,Oj^0. 


Definition.  A  state  is  dynamically  protected  if  it  satisfies  both  the  dynamic  secu¬ 
rity  and  the  dynamic  integrity  properties. 
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3.3.3  Consolidated  Static  and  Dynamic  Protection.  The  simiiitaneous  fulfillment  of 
both  static  and  dynamic  security  leads  to  the  following  ordering  of  the  security  levels 
corresponding  to  subject-object  interactions: . 

(s,o,r)eB  =t> /c(s)>/o(o) 

(s,o,w)eB  => /c(s)  =  /o(o) 

{s,o,a)€B  =i> /c(s)</o(o) 

\ 

for  all  sCS,  o€.0 .  Similarly,  the  fulfillment  of  both  static  and  dynamic  integrity  results 
in  an  ordering  of  integrity  levels: 

{s,0,t)€.B  =>  Pe(s)<Po(o) 

(s.o.w)e5  geis)  =  go{o) 

{s,o.a)€B  =>  gc{s)>9oio) 

for  all  s€.S,  o€0. 

3.3.4  Discretionary  Protection. 

Definition.  A  state  q  ^{B  ,M  M  .F  ,G)  obeys  discretionary  protection  (or, 
equivalently,  discretionary  security  or  discretionary  integrity)  if  and  only  if: 

(Si,Oj,x)€B  =0 


Definition.  A  state  q  =  (B ,M ,H ,F,G)  is  safe  (or,  equivalently,  protected)  if  it 
obeys  the  rules  of  static  protection,  dynamic  protection,  and  discretionary  pro¬ 
tection. 

3.4  Theorems 

This  section  introduces  a  number  of  protection  theorems,  which  form  the 
basis  of  the  proofs  of  the  primitive  operations  of  the  model.  Some  of  the  theorems  are 
presented  as  results  which  are  of  interest,  but  perhaps  not  directly  required  in  the 
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proofs  of  the  primitives.  They  do,  however,  provide  us  with  the  necessary  formal  tools 
for  discussing  the  behaviour  of  the  system  under  conditions  which  are  of  interest  when 
considering  the  preservation  of  security  and  integrity.  An  illustrative  set  of  primitive 
functions,  and  their  proofs  of  safety,  are  given  in  Chapter  4. 


Theorem  3.1.  The  system  K('J'),  zq)  is  sLalically  prulecled  for  any  initial  state 

zo  which  is  statically  protected  if  and  only  if  (iff),  for  'each  configuration 

1.  Every  (s ,  o ,  x)  c  5'  -B  satisfies  static  protection,  and 

2.  Every  {s,o,x)€B  which  does  not  satisfy  static  protection  relative  to  F'  and  C 
is  not  in  B' . 


Proof.  Suppose  Zq  =  {B ,M ,H ,F ,G)  is  an  initial  state  which  satisfies  static  protection. 
Choose  some  sequence  of  operations  {X,Y,Z)€E{R^  ,R^  Now,  {x  irV  i,  z  i,  z  c) 

is  in  V.  We  can  therefore  show  that  zi  satisfies  static  protection  by  demonstrating  that 
each  (s,  o ,  x)  €  1  of  state  z  i  is  statically  protected. 

Suppose  that  (s,  o,x)e:5  j.  Then  (s,  o,x)  must  be  in  3i  —  Bq  or  in  B  inBo,  since 
the  union  of  these  is  B  i.  If  the  former,  then  (s,o,x)  is  statically  protected  according 
to  (l).  If  the  latter,  then  (s,o,x)  is  statically  protected  according  to  (2).  Hence  Zj 
satisfies  the  static  protection  property.  By  induction  over  successive  states,  Z  is  stati¬ 
cally  protected,  so  that  the  instantiation  (X,Y^Z)  is  as  well.  Since  X.  Y,  and  Z  are 
arbitrary,  Zq)  is  statically  protected. 


To  prove  the  "only  if"  case,  suppose  Zq)  is  statically  protected 

for  anv  initial  state  Z"  which  is.  Then  h'^  contradiction  either  ^1)  or  ^2^  leads 

to  the  conclusion  that  there  must  be  some  (s ,  o ,ii)  € B'  which  is  not  statically  pro¬ 
tected  for  some  configuration  {x'  ,y'  ,z\z).  Hence  z'  is  not  statically  protected. 


(X,Y,Z)  is  not  statically  protected,  and  so  S(/? 2:0)  is  not  statically  pro¬ 
tected.  contradicting  the  original  assumption  of  the  argument.  Q 
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The  first  predicate  of  this  theorem  is  clear  in  intent.  The  second  predicate  is  required 
because  authorizations  in  B  that  remain  untouched  in  state  q'  may  stiU  violate  static 
protection,  if  the  level  functions  P  and  G'  in  the  new  state  have  undergone  alterations 
which  invalidate  authorizations  previously  consonant  with  protection  in  q.  If  there  is 
any  doubt  of  this,  the  relationship  between  G,  and  static  protection  presented  in 
Section  3.3.1  can  be  reviewed. 

s 

Theorem  3.2.  The  system  T.{R^  ,R^ ,V{^),zq)  is  dynamically  protected  for  any  initial 
state  zq  which  is  dynamically  protected  iff,  for  each  action  q’ ,q)^V: 

1.  Every  (s,o,i)eJ5'  -B  satisfies  dynamic  protection,  and 

2.  Every  (s,  o ,  x)  £ 5  which  does  not  satisfy  dynamic  protection  relative  to  F  and 
G'  is  not  in  B’ , 

Proof.  The  proof  identically  follows  that  of  Theorem  3.1.  □ 

Theorem  3-3-  The  sjrstem  E(R^  ,R^,  F(^),  Zq)  satisfies  discretionary  protection  for  any 
initial  state  Zq  which  satisfies  discretionary  protection  iff,  for  each  action 
(R^i,R^j-,q\q}eV: 

1.  Every  (s,o,x)eB'  -B  satisfies  discretionary  protection,  and 

2.  Every  (s,o,.x)£S  which  does  not  satisfy  discretionary  protection  relative  to 
F'  and  G'  is  not  in  J9' . 

Proof  The  proof  identically  follows  that  of  Theorem  3. 1.  D 

Corollary  3.1.  The  system  EiR'^ ,R^,V('^),Zq)  is  safe  iff  zq  is  a  protected  state  and  V 
satisfies  the  conditions  of  Theorems  3.1.  3.2,  and  3.3  for  configuration  in  V.  G 
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The  next  three  theorems  demonstrate  that,  if  the  set  of  primitive  functions  ^  of 
the  model  are  correctly  implemented,  then  the  previous  results  demonstrating  protec¬ 
tion  over  £  are  in  fact  attainable.  The  results  are  intuitively  obvious. 

Theorem  3.4.  If  is  a  set  of  primitive  functions  obeying  static  protection,  then 
£(/?*. /Z®,  7(^), zq)  satisfies  static  protection  for  an  initial  state  zq  which  satisfies  static 
protection. 

Proof.  Suppose  7(^),  zq)  statically  protected.  Then,  there  must  be 

some  (X,y,Z)€'E  which  is  not  statically  protected.  Let  t  be  the  smallest  element  of 
the  Lime  sequence  T  such  that  does  not  obey  static  protection.  Hence  is 

statically  protected  and  f  >0,  since  zq  satisfies  static  protection.  But  by  definition  of  E. 
(xi,yt,zt,Zi-i)€'E(R^ ,V{'^),Zo)  since  zt-i'r- Zf.  Moreover,  by  the  definition  of  H(^), 
there  must  be  some  primitive  function  ■{}/€. 'if  such  that  ,  z^-i)  =  (vf ,  Zf ).  Since  z<_i  is 
statically  protected  and  preserves  static  protection  by  proposition,  Zt  must  be  stati¬ 
cally  protected.  This  contradicts  our  original  premise,  so  the  system 
E(R^  ,R^,  Zq)  must  be  statically  protected.  Q 

Theorem  3.5.  If  ^  is  a  set  of  primitive  functions  obeying  dynamic  protection,  then 
E(/?® , Zq)  satisfies  dynamic  protection  for  an  initial  state  Zq  which  satisfies 
dynamic  protection. 

Proof.  The  proof  identically  follows  that  of  Theorem  3.4.  □ 

Theorem  3.6.  If  '5^  is  a  set  of  primitive  functions  obeying  discretionary  protection,  then 
7(4^),  Zq)  satisfies  discretionary  protection  for  an  initial  state  zq  which 
satisfies  discretionary  protection. 
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Proof.  The  proof  identically  follows  that  of  Theoroxii  3.4.  fi 

The  importance  of  these  results  is  summarized  in  the  following  corollary. 

Corollary  3.2.  sto)  is  safe  for  an  initial  state  zq  which  is  safe,  and  an 

arbitrary  set  of  safe  primitive  functions  □ 

\ 

Having  laid  the  basic  theoretical  framework  regarding  the  system  and  its  primi¬ 
tive  functions,  we  can  now  present  results  which  guarantee  that  protection  will  be 
preserved  over  certain  desirable  categories  of  state  changes.  These  results  are  central 
to  the  proofs  of  the  primitive  functions  themselves. 

Theorem  3.7.  Suppose,  g  =  {B  ,M ,H ,F ,  G)  is  a  state  which  satisfies  static  protection. 
Let  B’ \jI(s  B  and  q' =(B' ,G),  M,  H,  F,  and  G  being  invariauit. 

Then  g’  obeys  static  protection  iff: 

1.  x=  e,  or 

2.  x  =  r  /j{s)>/o(o).  or 

3.  x  =  w  => /s(s)>/o(o)  and  gs(s)>go(o),  or 

4.  gs{s)>go{o). 

Proof,  Suppose  q'  obeys  static  protection.  Then  {s,o,obs)€S'  =i> /s(s)  >/o(o)  and 
(s,o,  mod)  €5’  =>  gs(s)>go(o)  by  definition.  Since  xe|e,  r,  w,  aj,  (l)  through  (4)  are 
collectively  exhaustive  and  so  (exactly)  one  of  them  must  hold. 

It  remains  to  be  shown  that  if  one  of  the  four  conditions  holds,  then  q'  is  stati¬ 
cally  protected.  Observe  that  if  (l)  holds,  then  q'  is  trhdally  statically  protected  since 
q  is.  (2),  (3),  and  (4)  are  consonant  "with  static  protection,  so  if  one  of  them  holds,  then 
immediately  (s ,  o ,  obs)  €  .S’  => /s(s )  > /o(o )  and  (s,o,mod)€S'  =>  g®  (s )  >  S^o  (o  )  for  all 
sCS  and  o€0,  since  q  is  statically  protected.  Hence  q'  is  statically  protected.  !j 
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Theorem  3.8.  Suppose  q  ={8  ,M,H,F,G)  is  a  state  which  satisfies  dynamic  protection. 
Let  B’ =8  and  q'  =(8\M,H,F,G),  M,  H,  F,  and  G  being  invariant. 

Then  q'  obeys  d5mamic  protection  iff: 

1.  K=  e,  or 

2.  x=r  =C> /e(s)>/o(o)  and  gc(s)<yo(o),  or 

3.  :x.  =  w  =>  and  gc{s)=go{o),  or 

\ 

4.  x=a  =t> /c(s)</o(o)  and 

Proof.  Suppose  q'  obeys  dynamic  protection.  Then  the  conditions  put  forth  in  (l) 
through  (4)  hold  for  all  s€:S  and  o€0  by  the  definition  of  dynamic  protection.  Con¬ 
versely,  if  one  of  (1)  through  (4)  holds,  then  q'  is  clearly  dynamically  protected  since  q 
is  djmamicgdly  protected  and  the  conditions  are  consonant  with  dynamic  protection.  □ 

Theorem  3.9.  Suppose  q  =  {8  ,M ,8 ,F ,C)  is  a  state  which  satisfies  discretionary  pro¬ 
tection.  Let  8*  =  8  u[(si,  Oj,x)]  ^  8  and  q'  ={8*  ,M,H  ,F  ,G),  M,  H,  F,  and  C  being 
invariant.  Then  g'  obeys  discretionary  protection  iff 

Proof.  Suppose  g'  obeys  discretionary  protection.  Then  x€.Mij  by  definition.  Con¬ 
versely,  if  then  the  condition  of  discretionary  protection  is  met  for 

{si,  Oj,x)  €.8' ,  so  g'  obeys  discretionary  protection.  □ 

Corollary  3.3.  Suppose  q  =  {8  ,M rH  ,F,C)  is  a  protected  state.  Let  B'-B  kj 
l(s,o,  x)J  ^8  and  g‘  =  (8' ,M ,H ,F ,G),  M,  H ,  F,  and  G  being  invau*iant.  Then  g’  is  a  pro¬ 
tected  state  iff  the  conditions  of  Theorems  3.7,  3.8,  and  3.9  hold.  □ 

The  previous  three  theorems  and  Corollar}^  3.3  apply  to  a  state  change  g  r- g' 
where  the  access  list  8'  is  augmented  to  include  an  additional  triple  not  active  in  8 . 
We  now  consider  the  minimal  conditions  under  which  access  can  be  removed  without 
compromising  protection.  The  simplicity  of  the  proof  rests  in  part  upon  the  invariance 


of  F  and  C . 
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Theorem.  3.10.  Let  q)  ^  j,  q' )  be  a  primitive  function,  where 

q=iB,M.H,F,G)  and  =  , IF  ,F  ,G').  Then,  if  B'QB.  F'-F,  and  G'-G, 

f{R^i,q)  preserves  both  static  and  d3mamic  protection.  Also,  if  andi/’^SA/y 

for  all  i,  j,  then  q)  preserves  discretionary  protection, 

Froof.  if  q  obeys  static  protection,  then  (s ,  o ,  obs)  <=  5'  =>  (s ,  o .  obs)  €  5  and 
(y ,  o, mod) €S’  =>  (s,  o,  mod)  €B  since  B'QB.  Hence,  /s(s )>/„(&)  and  Ps(s)>p6(o). 
But  P  =F  and  G'  =G.  Therefore,  q'  is  statically  protected  if  g  is  and  so  Tp{R^i,q) 
preserves  static  protection.  A  similar  argument  demonstrates  that  dynamic  and  dis¬ 
cretionary  protection  are  like-^vise  preserved,  ir 

Corollary  3.4.  Let  TpiR^ i,  q) {R^ g'' )  be  a  primitive  function,  where 
q  =  (B  ,M  ,H  ,F  ^G )  and  q'  =  (B' ,  M’ ,  H' ,  F' ,  G’).  Then  if  B'  CB  and  i/'y-  ^Afy-  for  all  i,  j ,  q' 
is  at  least  as  safe  as  q  over  Tp.  Q 

The  motiv0.tion  for  pro^^di^g  hierarchical  securit)?"  and  integrity  level  compati¬ 
bility  in  the  model  has  been  pre\'iousiy  discussed.  While  compatibility  is  not  directly 
included  in  the  semantics  of  a  "protected"  state  as  defined,  a  state  that  does  fulfill  all 
of  the  requirements  of  the  model  for  uncompromisable  operation  must  obey  compati¬ 
bility  by  our  design  choices. 

To  aid  in  proving  certain  statements  about  compatibility  in  the  primitive  opera¬ 
tions.  two  related  theorems  are  now  presented.  The  theorems  deal  specifically  with  the 
notions  of  adding  an  object  to  the  hierarchy,  and  changmg  the  levels  of  an  existing 
object  within  the  hierarchy,  both  of  which  could  violate  the  compatibility  of  the  resul¬ 
tant  state. 

Theorem  3.11.  Suppose  g  ={B,M,H,F,G)  is  a  state  vvhich  obeys  compatibility.  Then 
any  new  object  0  which  is  added  to  H  with  the  same  security  and  integrity  levels 
as  its  ancestor,  does  not  compromise  the  compatibility  of  the  resultant  state 
g*  =  (B‘ ,  M'  ,H\F\G‘ ). 
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Proof,  Since  q  obeys  compatibility,  fo{ha{oy))  must  be  dominated  by  every  h^{ha{oy)) 
before  Oy  is  inserted  into  the  hierarchy,  and  conversely,  go(^a(Oy))  must  dominate  each 
^d(f^(oy)).  But  in  q’,  fo'(^a(oy))  =  fo'(o7)  and  ffo'(ha(oy))  =  go'(oy)  by  proposition.  It  is 
therefore  cleeo*  that /^(oy) < and  po (oy) > for  eauh^^(uy)„.  Moreover, 
<  is  transitive  and  so  applies  bidirectionally  to  ha(oy)  and  h^(oy).  Kence  g'  preserves 
compatibility  in  the  hierarchy.  □ 

\ 

Theorem  3.12.  Suppose  q  ■=  {B  ,M ,H ,G)  is  a  state  -which  obeys  compatibility  and  let 
i/iR^i,q)  j,q’)  be  a  primitive  function.  If  fo’{oj)  =  k  and  gQ'{oj)  =  l,  then  q' 

preserves  compatibility  iff; 

yo(^a(Oj))>i  go(hd(Oj)m)  <  I 

for  each  h^{oj)„^. 

Proof  Suppose  q'  is  a  compatible  state.  Then  f^  radiating  from  the  root  node  must 
be  monotonicEilly  non-decreasing,  and  go  must  be  monotonically  non-increasing.  The 
conditions  of  the  theorem  immediately  hold.  Conversely,  if  fc  is  increasingly  bounded 
/o(^(oj))  and  each  /<>  then  since  q  is  compatible  and  by  the  transitivity 

of  <,  k  is  bounded  by  each  fo{h,a{oj)m)  aJid  fo{^d(oj)m)-  Analogously,  if  I  is  decreas- 
ingly  bounded  by  goi^ai^j))  sii^d  each  goi^d{^j)m)>  then  it  is  also  bounded  by  each 
Po(^(oi)m)  and  Po(^d{oi)m)-  Hence  q'  is  compatible.  Q 


3.5  Summary 

This  chapter  has  presented  the  mathematical  foundations  required  to  estab¬ 
lish  the  formal  structure  of  the  model.  Within  this  structure,  it  is  no-w  possible  to 
define  and  model  a  set  of  primitive  operations  of  a  protected  computer  system,  and  to 
demonstrate  that  these  operations  do  in  fact  preserve  protection  in  a  multi-user, 


multi-le-vei  en-vironment. 


-67- 


A  number  of  protection-related  theorems  were  proved,  to  assist  in  the  formal 
analysis  of  a  working  set  of  primitives.  The  theorems  state  the  many  conditions  which 
must  hold  true  if  a  system  E{R^  .R^ .  K(^).  za)  is  to  remain  safe  over  a  state  transition. 
The  importance  of  these  results  will  become  clear  in  the  next  chapter,  where  a  typical 
set  of  kernel  functions  is  defined  and  proved  to  be  protection-preserving. 


4.  SAMPLE  KERNEL  PRIMITIVES  AND  PROOFS 


"/  can  ccdl  spirits  from  the  vasty  deep. " 

"Why  so  cart  I,  or  so  can  any  man; 
but  will  they  come  when>.you  do  call  for  them?" 

—  William  Shakespeare 

You  know  my  methods.  Apply  them. 

—  Sir  Arthur  Conan  Doyle 

The  formal  design  of  the  representation  of  subjects  and  objects  in  a  protection 
mechanism  is  only  part  of  the  solution  to  providing  a  multi-level  secure  computing 
environment,  for  we  must  still  consider  the  specification  of  a  set  of  operations  which 
govern  the  interactions  between  elements  in  the  system.  This  is,  in  a  sense,  an  exten¬ 
sion  of  the  protection  policies  that  have  been  developed;  what  is  required  is  effectively 
a  vehicle  to  model  the  implementation  of  these  policies  for  a  particular  environment 
with  specific  requirements. 

Naturally,  one  would  expect  different  computing  sites  to  have  different 
specification  requirements,  stemming  from  the  nature  of  the  facilities  they  wish  to  pro- 
’.dde  to  their  users.  Dissimilarities  may  also  arise  at  the  machine  implementation  level, 
owning  to  different  machine  hardware  and  architecture.  An  important  distinction  can 
therefore  be  made  bsUveen  the  protection  poiicies  and  the  protection  operations.*  The 
policies  have  been  developed  to  reflect  military  security  requirements,  and  are  the 
basis  for  proving  the  model  to  be  safe  and  correct.  They  ai'e  relatively  fixed,  and  are 
not  intended  as  site-dependent,  alterable  paranielers.  The  protecLioa  operations,  on 
the  other  hand,  embody  the  mathematical  model  as  well  as  the  protection  policies,  and 
can  implement  any  facility  that  the  mathematical  framework  can  support.  Hence,  the 

•  A  clear  discussiori  of  cin  analogous  distinction  may  be  found  in  the  literature  pertaining  to  the  HYDRA 
system  (see  Wulf  [»V’’ulf74]  and  Cohen  [Cohe75],  for :  example).  Although  di^erent  terms  ai"e  used,  the 
iinder lying  concepts  ai’e  parallel. 
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kernel  operations  developed  here  are  merely  sample  solutions,  to  demonstrate  haw 
certain  facilities  might  be  provided  should  they  be  required.  Emphasis  was  placed  on 
practicality  and  flexibility,  while  trying  to  provide  a  full  complement  of  information 
processing  capabilities.  However,  a  speciflc  implementation  of  the  model  might  involve 
some,  all,  or  none  of  the  solutions  given. 

The  theorems  developed  in  Chapter  3  establish  the  inductive  nature  of  protec¬ 
tion  within  the  model,  by  showing  that  the  preservation  of  protection  from  any  state 
known  to  be  safe  to  any  other  state  guarantees  total  system  protection.  The  primitive 
operations  make  direct  use  of  this  result,  by  providing  a  general  framework  within 
which  single  state  transitions  can  be  isolated,  identified,  and  defined. 

The  primitive  functions  correspond  to  allowable  kernel  requests  from,  subjects, 
or  users  of  the  system.  Each  function  is  serially  restartable,  provided  that  individual 
statements,  particularly  return  statements,  are  non-interruptable.  Each  function 
takes  a  list  of  parameters  as  its  argument.  The  function  processes  these  parameters 
and  applies  them  to  the  current  system  state,  producing  a  result  and  a  new  current 
state.  Thus,  each  class  of  incoming  requests  is  analyzed  separately  in  a  function 
specifically  designed  to  handle  that  particular  class.  This  modularity  is  not  unduly  res¬ 
trictive,  and  indeed  is  w’-hat  proper  programming  practice  might  independently  advo¬ 
cate. 

To  avoid  ambiguity,  no  tv;-o  primitive  functions  may  service  the  same  type  of 
request;  should  the  set  of  primitives  accidentally  contain  duplication,  some  machinery 
in  the  system  (not  shown  here)  returns  the  result  "error'',  vvith  no  eneetive  state 
change.  Note  that  this  does  not  preclude  the  possibility  of  (perhaps  experimentally) 
providing  different  approaches  to  the  same  class  of  requests  via  different  kernel  func¬ 
tions.  The  approach  that  works  the  best  can  then  be  chosen  empirically.  This  gives  the 
model  flexibility  which  can  be  of  great  use  in  tailoring  it  to  a  speciflc  application. 
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In  the  remainder  of  this  chapter,  we  develop  a  sample  set  of  kernel  functions, 
and  prove  that  these  functions  are  protection-preserving  with  the  aid  of  the  results  of 
the  previous  chapter.  The  demonstration  that  a  particular  primitive  is  safe  can,  in 
many  cases,  be  reduced  to  direct  consideration  of  the  small  number  of  state  element 
modifications  involved  with  that  particular  state  transition. 

\ 

4.1  The  Primitive  Kernel  Functions 

In  Chapter  2,  we  introduced  and  discussed  various  types  of  input  requests  that 
the  kernel  of  a  computer  system  might  wish  to  support.  The  requests  included  han¬ 
dling  alterations  to  the  access  levels  (B),  to  the  need-to-know  access  matrix  (M),  to 
the  object  hierarchy  (H),  and  to  the  security  and  integrity  level  functions  (F  and  G). 
These  classes  of  primitive  functions  are  now  presented  formally.*  The  notation  iTp^ 
and  lipM  is  used  to  represent  the  dimension  of  the  first  and  last  axis  of  the  matrix  il/, 
respectively, 

4.1.1  Gef_rea«i,  Get _ append.  Get_write.  Get _ execute.  The  kernel  functions  described 

in  this  section  permit  a  subject  to  be  granted  access  to  an  object  in  a  particular  mode. 
The  protection  policies  implied  by  the  mode  arc  sufficiently  dificrent  to  warrant 
separate  presentation  of  the  functions,  to  avoid  complicating  the  associated  condi¬ 
tional  logic. 


*  Andrews  [Andr74]  and  Bell  and  La  Padula  [Bell75b],  among  others,  describe  different  classes  of  utilities  for 
other  protection  environments  having  different  mathematical  foundations. 
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procedure  get_read{si,  Oj) 

/* 

*  Request  from  subject  for  access  to  object  oy  in  read-only  (r)  mode. 

V 

begin 

if  Si  c  iS*  and  Oj  e  0  tlien 

if  reMy  and  fc{si)> amd  9c(si)<go{oj)  then 
begin 

\ 

B  ^  B  \J  Oj.  r)i 

return(/?*jfe,  q’)  =  (valid,  (B  ,M,H,F,  G  )) 

end 

else 

return(/?®|. ,  q')  =  (invalid,  q  ) 

else 

return(R®  fc .  g' )  =  (illegal,  q  ) 
end  get_read 


procedure  get_append{s^,  Oj) 

/* 

♦  Request  from  subject  for  access  to  object  Oy  in  append-only  (a)  mode. 

•/ 

begin 

if  and  Oj-  €  0  then 

if  acAfy  and  fe(^i)<fo(o;)  and  gc(^i)> ffoCoj)  then 
begin 

B  B  \J  a)| 

retuFii(/i  ,  g' )  —  \  valid,  (JS  ,  M ,  M ,  F ,  Gy) 
end. 
else 

return(i?  =  (invalid,  q ) 

else 

return(i?®i .  g’ )  =  (illegal,  g  ) 
end  gei__apvend 
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procedure  get_write  (s*,  o^) 

/♦ 

♦  Request  from  subject  for  access  to  object  oy  in  write  (ir)  mode. 

•/ 

begin 

if  Si  G  S'  and  Oj  €.0  then 

if  weMij  and  /c(si)  =  /o(oy)  and  gdsi)  =  go{oj)  then 
begin 

B  B  V  [{Si,  Oy.  w)| 

retTirn(/?®fc,  g')=  (valid.  (B  ,M,H ,F,G)) 
end 
else 

return(R  *  jt ,  q’)  =  (invalid,  q  ) 

else 

return(/?®ifc  ,q’)  =  (illegal,  q  ) 
end  get^write 


procedure  gei^execute  (sf,  oy) 

/♦ 

♦  Request  from  subject  Si  for  access  to  object  oy  in  execute  (e)  mode. 

*/ 

begin 

if  Si  €  S  end  Oy  e  0  then 
if  eeA/iy  then 
begin 

B  -^  B  u  |(si,  Oy,  e)^ 

return(7?®t,  q’)  =  (valid,  {B  ,M,H,F,G)) 
end 
else 

retum(R  ,  g' )  =  (invalid,  g  ) 

else 

return(R  ,  g' )  =  (illegal,  g  ) 
end  get_e.xemite. 


4.1.2  Deleie^ead,  Delete_append,  Delete_'WTite,  Delete^execute.  These  kernel  func¬ 
tions  handle  requests  by  a  subject  to  relinquish  its  access  to  an  object  in  a  particular 
mode.  The  primitives  ser^re  in  part  to  support  the  need-to-know  principle  of  least 
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access  in  the  computer  system. 

procedure  dslBte^read /append /write /2xecutB^{si,  Oy) 

/* 

♦  Request  from  subject  to  delete  access  to  object  Oy  in  read  (r), 

♦  append  (a),  write  (w),  or  execute  (e)  mode. 

♦  The  access  attribute  is  denoted  by  . 

V 

\ 

begin 

if  Sj  e  and  Oy  e  0  then 
begin 
B  ^  B 

retum(i? ® jt •  (valid,  {B  ,C)) 

end 
else 

return(/?*i .  g' )  =  (illegal,  q  ) 
end  delete_T£ad  /append  /write  /execut  e 


4.1.3  Cranf^jTBad.  Grant^append,  Gra7it..jurnie,  Grant^execute,  These  kernel  func¬ 
tions  handle  third-person  requests  to  extend  some  form  of  access  to  a  subject.  Here, 
the  subject  making  the  request  does  so  on  behalf  of  another  subject.  To  handle  the 
validity  of  granting  (or  revoking)  access  to  an  object  when  the  hierarchy  root  node  oj? 
is  involved,  we  define  an  additional  pragmatic  constraint  function,  n(s,o,g,t),  where  t 
is  "grant"  or  "revoke"  and  n(s,o,g,t)  is  true  if  and  only  if  s  is  allowed  to  effect  the 
access  modification  specified  by  t  to  object  o  in  the  state  q.  The  inverse  revocation  of 


access  is  discussed  in  the  next  section. 
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procedure  gra7it_readj/iijypend/write /execute {s,Si,Oj) 

/♦ 

♦  Request  from  subject  s  to  grsuit  subject  access  to  object  Oj  in 

♦  read  (r),  append  (a),  write  (w).  or  execute  (e)  mode. 

♦  The  access  attribute  is  denoted  by  x€i4  . 

♦/ 


begin 

if  s  €  5*  and  and  Oy  €  0  then 

if  ha{oj)e\(p,oii]  and  n(s,  Oy,g, grant) 

\ha{.Oj)/\v,OR\  and  (s  . /ia{oy),  w)  €5 


or 


then 


begin 

%  Mij  u  |xi 

retnrn(i?  ®  jfc ,  g')  =  (valid,  (B  ,M,H  ,F,  G)) 

end 

else 

retum(i? ,  g' )  =  (in'^id,  g  ) 

else 

return(/2®jt ,  g’ )  =  (illegal,  g ) 
end  grant^read  /append  /vjrite  /execute 


4.1.4  Revoke^read.  Revoke^append.  Revoke^write,  Revoke_execuie,  These  kernel 
functions  complement  the  preceding  set,  and  provide  capabilities  to  perform  third- 
person  access  relinquishment.  The  constraint  function  n(s,  o,  g,  t)  is  used  here  as  well. 


with  t=  revoke. 
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procedure  revolcQ_T£ad /append /'wtUq /exQcute  (s ,  s< ,  Oj) 

/* 

♦  Request  from  subject  s  to  revoke  subject  s^'s  access  to  object  Oj  in 

♦  read  (r),  append  (a),  write  (w),  or  execute  (e)  mode. 

♦  The  access  attribute  is  denoted  by  x€i4  . 

♦/ 


begin 

if  s  €  5  and  G  S  and  n^€.0  then 

if  and  n(s ,  o^- ,  q , revoke)|  or 

and  (s,/ia(o;),  w)  esj  then 

begin 

Mij  *r-  Mij  -  Ixj 

B  B  -  \{si,Oj,K)] 

retum(/?®jt,  q')  =  (valid,  {B  ,M,H ,F,G)) 

end 

else 

retum(/?  ®  jt ,  g' )  =  (invalid,  g  ) 

else 

return(R®jb ,  g' )  =  (illegal,  g  ) 
end  revoke_read  /append  /write  /execute 


4.1,^  Creede^object,  Delete^object,  Delete^object^tree.  The  three  kernel  functions 
described  in  this  section  effect  changes  to  the  object  hierarchy,  by  creating  or  des¬ 
troying  objects.  The  two  forms  of  object  deletion  differ  in  that  deleie^object  purges 
Just  a  single  element,  moving  all  others  inferior  to  it  higher  in  the  hierarchy,  while 
delete^object^tree  purges  the  designated  object  and  all  those  beneath  it. 
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procedure  create_Qbject{si,Oj) 

/♦ 

♦  Request  from  subject  to  create  a  new  object  below  object  Oy  in  the 

♦  hierarchy. 

♦  The  new  object  is  given  the  security  and  integrity  levels  of  its  parent,  Oy. 

♦/ 

begin 

if  Si  €  5"  and  Oy  £  Q  then 
if  (si ,  Oy .  mod)  €  B'  then 
begin 

7  min{i: /la(Oi)  =  OP  and  Ki^lipM) 

fo  fo  ^f(oy,fo(oj))l 

9o  ^  9o  ^Koy.  90(03))] 

H  ^Hu[{o,,ay)] 

return  (R^k,q')  =  (valid,  (B  . M. H,F.G)) 

end 

else 

return(/?  ®  ,  ?' )  =  (invalid,  q ) 

else 

returii(R ^  jt ,  g' )  =  (illegal,  q ) 
end  create__object 
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procedure  delete^object  {si ,  Oj) 

/* 

♦  Request  from  subject  to  delete  object  from  the  hierarchy. 

♦  Objects  inferior  to  Oj  are  propagated  upward, 

♦/ 

begin 

if  Si  €  S'  and  Oy  €  0  then 

if  Oj  Or  and  (si.0y,w)€5  then 
begin 

D  *-  B  -\{S  y.Oj'<A)]nB 
for  m  1  to  I  tpM  do 
Mmj  *-  '■? 

H  *-  H  -KK{0s).aj)] 

ret'ULrii(/k  j;. ,  5'  )  —  { Tetlidj  {B  ,  if ,  M ,  B ,  C- )) 

end 

else 

return(R  *jfe  ,q')  =  (invalid,  q  ) 

else 

return(/?®j|j  ,q')  =  (illegal,  q ) 
end  deiete^object 
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procedure  delete_object_tree(si,  oj) 

/* 

♦  Request  from  subject  to  delete  object  Oj  and  all  objects  inferior  to  it 

*  in  the  hierarchy. 

V 

be^n 

if  Si  €  iS*  and  Oj  cO  then 

if  Oj  ^  ojt  and  (si .  ha  (oy ),  w)  e  5  then 
begin 

D  h-dioj) 

for  m  <-  1  to  do 
begin 

B  ^  B  -{(S  X0yXA)]nB 
for  n  *-  1  to  ItpAf  do 

Mny  <-  (p 

H  H  -  i{ha(oy),Oy)] 
end 

retum(/2®js.,  g')  =  (valid,  {B  G)) 

end 

else 

retum(/?  ®  fc ,  g' )  =  (invalid^  g  ) 

else 

return(/?®i; ,  g' )  =  (illegal,  g  ) 
end  delete__object_iree 


4.1.6  Change_jsubJect_secu‘rUy_level,  Chartge_s7iJbject_Jbn.tf>gTiiy_levcl.  These  two 
kernel  functions  serve  to  let  a  subject  alter  its  current  security  level,  /c.  or  its  current 
integrity  level,  g^.  Subjects  are  intended  to  operate  with  the  least  possible  protection 
levels  that  are  sufficient  to  enable  them  to  perform  their  respective  tasks.  This 
reduces  the  risk  of  accidental  damage  beyond  what  the  protection  model  could  enforce 
solely  via  non-discretionary  controls. 
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procediire  change__subject_security_level{si,k) 

/• 

♦  Request  from  subject  to  change  its  current  security  level  to  k 

•/ 

begin 

if  Si  €.S  and  ki€.K^  and  kz^K^  tlien 

if  and  {si.Of.T)cB  ^  fc(si)>k 

and  (si,  Oj,^)eB  =>  /g (si )-k 
and  (si.  Oj ,  a) e 5  —>  fc{si)<k  then 

begin 

return(R®fc,  q’)  =  (valid,  {B  ,M ,H ,F ,G)) 
end 
else 

retiim(/?  ®  ,  g' )  =  (invalid,  q ) 

else 

return(i?®  ,q')  =  (illegal,  q  ) 
end  change_subject_security_leveL 


procedure  change^subject^integrity^Level (s^,  Z ) 

/* 

♦  Request  from  subject  to  change  its  current  integrity  Level  to  I 

V 


begin 

if  Si€.S  and  li€L^  and  then 

if  9s(si)>l  and  (si.Oj.r)  eB  ^gc{si)<l 
and  {si,Oj,w)  =i>  g^{si}=l 
and  {Si,Oj,a)€.B  =>  gc{si)>l  then 


gc(si)  *-  I 

retuni(i?®i; ,  g' )  =  (valid,  (B  ,M  ,H  ,F  ,G)) 
end 
else 

reliirn(/?  ®  * ,  g'  )  =  (invalid,  q  ) 

else 

return(i?®i ,  g’ )  =  (illegal,  g ) 
end  change^subject_i7itegTity_level 
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4.1.7  ChxEnge^jabject^etniTiJty^level,  Cha7ige_object^vrUegriiy_Jevel.  The  kernel 

functions  described  next  permit  a  subject  to  alter  the  security  level  of  an  object,  or 
the  integrity  level  of  an  object,  go-  As  with  subject  jurisdictions,  objects  should  assume 
the  lowest  possible  levels  they  can  at  all  times. 

procedure  change_object_secuTity_level{si,  0j,k) 

/• 

\ 

♦  Request  from  subject  Sj  to  change  the  security  level  of  object  Oy  to  k. 

•/ 


begin 

if  St  €5  and  k^^K^  and  k^QK^  then 
if  fc  {si)>  k  and  fo {oj)  <k  then 
begin 

for  m  •*-  1  to  1  ^pM  do 

if  -[(s^,0y,r)€5  =>/c(sm)>^ 
and  (sm.o^,w)€.B  =>/c(s„»)  =  A: 
and  (s^.0y,a)e5 

return(/i“'jt  ,q')  =  (invalid,  q ) 
if  fo{^{oj))<k  then 
begin 


then 


D  ^  h^{oj) 
for  m  1  to  do 
if  -’/o(^m)>fc  then 

retum(/?  ,q')  =  (invalid,  q ) 


/o(oy)  k 

return(/i  ^  jt ,  g' )  =  (valid,  (B  .  M ,  H ,  F ,  G)) 


end 


end 

return(/?*jt  >q')  =  (invalid,  q  ) 
else 

return(^®jfc  ,q')  =  (illegal,  q ) 
end  change^object_secuTity_level 
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procedure  change^object_integrity_level  (si,  oj,  I ) 

/♦ 

♦  Request  from  subject  to  change  the  integrity  level  of  object  Oj  to  i. 

•/ 

begin 

if  Si  €S  and  and  then 

if  9c(si)>l  and  go(oj)<l  then 
begin 

for  m  <-  1  to  ItpJI/  do 

if  -((sTO.o^.r)€5  =^gc{Sm)<l 
and  {s„i.oy.w)e5  =>  gc(sm)  =  l 
and  {sm ,  oy .  a)  e  5  =t>  (s^  )  >  then 

return(/?  ®  fc .  g' )  =  (invalid,  q  ) 
if  9o(.f^a{oj))>^  then 
begin 

D  -e  hdioj-) 
for  TTl  ^  1  to  "^D  do 
if  then 

retum(i?®  jb ,  g’)  =  (invalid,  q ) 

9o(oj)  <-  I 

rcturn(/?^;j.  ,q’)  =  (valid,  (B  ,M,  H,F,G)) 

end 

end 

return(/?®  *  ,q')  =  (invalid,  g ) 
else 

retum(/?®j|. ,  g' )  =  (illegal,  g ) 
end  charige_Qbject_J,ntegrity_level 


4.2  Safety  Proofs  of  the  Primitives 

Having  defined  a  sample  set  of  primitives  we  can  now  demonstrate  formally 
that  each  kernel  function  preserves  protection  as  it  is  supposed  to.  Then,  given  an  ini¬ 
tial  state  Zq  which  is  safe,  each  action  7(^)  must  be  safe,  and  so  the  system 
E(R^,R^,  V('^),Zq)  is  safe  by  Corollary  3.1. 
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In  each  safety  proof,  we  omit  a  discussion  of  the  degenerate  case  where  no 
state  transition  occurs  and  g'  =  g ,  for  this  is  clearly  protection-preserving  since  the 
current  state  g  is  safe.  The  proofs  follow  the  same  order  as  the  primitives  in  the 
preceding  section. 


4.2.1  Get^Tead,  Suppose  g  is  a  protected  state.  If  g' ^  g .  thpn  q'  is  a  function  of 
B’ =3  B .  Since  /c(st)>/o(o^),  and  recalling  that  /s  (s< )  > /g  (s< )  by 

definition,  q'  obeys  static  protection  by  Theorem  3.7.  Since  we  also  have  gdsi)  <goioj)> 
q'  obeys  dynaimic  protection  by  Theorem  3.8.  Further,  so  q*  obeys  discretion¬ 

ary  protection  according  to  Theorem  3.9.  Hence  q'  is  a  protected  state,  and  the  primi¬ 
tive  preserves  proLeclLoii  by  Corollary  3.3. 

d.2.2  Get_appeTid,  Suppose  g  is  a  protected  state.  If  g'  ?*g.  then  g'  is  a  function  of 
B’ =B  .  Since  gc(si)>  g^iof),  and  recalling  that  gs{si)>  gc{si)  by 

definition,  g'  obeys  static  protection  by  Theorem  3.7.  Since  we  also  have 
fc{si)<fo{oj),  q'  obeys  dynamic  protection  by  Theorem  3.8.  Further,  so  q' 

obeys  discretionary  protection  according  to  Theorem  3.9.  Hence  g'  is  a  protected 
state,  and  the  primitive  preserves  protection  by  Corollary  3.3. 

4.2.3  Get_VTritQ.  Suppose  g  is  a  protected  state.  If  q'  ^q,  then  g'  is  a  function  of 
B’ =B  B .  Since  /cC^^)  = /oCof )  and  gdsi)  =  and  recalling  that 

fs{^i)^fci^i)  definition,  g'  obeys  static  protection  by  Theorem 

3.7  and  dynamic  protection  by  Theorem  3.8.  Further,  wCil/^ ,  so  g'  obeys  discretionary 
protection  according  to  Theorem  3.9.  Hence  g'  is  a  protected  state,  and  the  primitive 
preserves  protection  by  Corollary  3.3. 


4.2.4  Get^execute.  Suppose  g  is  a  protected  state.  If  q’  ^  q ,  then  q'  is  a  function  of 

B' =B  .  Since  "execute"  access  is  exempt  from  static  and  dynamic 

protection,  g'  trivially  satisfies  both  of  these  forms  of  protection  by  Theorems  3.7  and 
3.8,  respectively.  Further,  since  e€jfy,  g’  obeys  discretionaiy  prolecLiori  according  to 
Theorem  3.9.  Hence  g'  is  a  protected  state,  and  the  primitive  preserves  protection  by 
Corollary  3.3. 

4.2.5  Deleie,^ead,  Delete _ append,  Delete^write,  Delete _ execute.  Suppose  g  is  a  pro¬ 
tected  state.  If  q' ^  q ,  then  g’  is  a  function  of  B'  =B  B  vrhere  x€,A, 

Since  B*  QB  with  F  and  G  invariant,  the  primitive  preserves  both  static  and  dynamic 
protection  by  Theorem  3.10.  Moreover,  since  M'  =Af,  discretionary  protection  is 
preserved  (Theorem  3.10).  Hence  g'  is  a  protected  state,  and  the  primithre  preserves 
protection. 

4.2.6  GTa7vt__Teadt  GrtrrU_appemd,  Grant^jurrite,  GrarU_execute.  Suppose  g  is  a  pro¬ 
tected  state.  If  g'  ^  g,  then  g'  is  a  function  of  M'  where  Af'i-  —Mij  u  and  .  Since 

for  all  i,  and  since  B,  F,  and  G  are  invariant,  g’  is  a  protected  state,  and 
the  primitive  preserves  protection  by  Theorem  3.10. 

4.2.7  Revoke^read,  RevQke_ajypend,  Revoke^write,  Revoke_execute.  Suppose  g  is  a 

protected  state.  If  g'  ^g,  then  g'  is  a  function  of  /?'  =  ^  ^  where 

M'ij=Mij  —  and  x^A  .  Since  B'  QB  with  F  and  G  invariant,  the  conditions  of  the  first 
part  of  Theorem  3.10  hold  and  the  primitive  preserves  both  static  and  dynamic  protec¬ 
tion.  Further,  discretionary  protection  is  clearly  preserved  since  B  and  M  are  dimin¬ 
ished  in  parallel,  so  that  (sfi.,0i,x)€B'  =>  xcM'f-i  for  all  fc,  I  in  g'.  TTence  g'  is  a  pro¬ 
tected  state,  and  the  primitive  preserves  protection. 
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4.2.8  Create^object»  Suppose  qr  is  a  protected  state,  and  assume  q'  ^  q .  B  and  M  are 
invariant,  and  since  {s,Oy,x)/tB  for  any  s  €  and  xeA,  q'  trivially  obeys  sialic, 
dynamic,  and  discretionary  protection.  Moreover,  g'  preserves  compatibility  by 
Theorem  3.11.  Hence  q'  is  a  protected  state,  and  the  primitive  preserves  protection. 

4.2.9  Delete^object,  Delete^object^tree,  (Although  these  primitives  were  presented 

separately,  their  proofs  of  protection  are  identical  and  hence  are  treated  in  unison 
here.)  Suppose  g  is  a  protected  state.  If  q'^q,  then  q’  is  a  function  of 
B’ =B  -  y^Oj^A^nB ,  M'  such  that  =  ^  for  all  m,  and  H’  =  H  —  i{ha{oj),Oj)l. 
Removing  one  or  more  objects  from  the  hierarchy  does  not  pose  a  protection  or  com¬ 
patibility  problem,  so  H  need  not  be  considered  further.  Now  B'  QB  with  F  and  G 

invariant,  so  the  conditions  of  the  first  part  of  Theorem  3.10  hold  and  the  primitives 
preserve  both  static  and  dynamic  protection.  Further,  discretionary  protection  is 
clearly  preserved,  since  the  operations  on  B  and  M  ensure  that 

^  s.£M']ci  for  all  A:,  £  in  g'.  Hence  g’  is  a  protected  state,  and  the  primi¬ 

tives  preserve  protection. 

4.2.10  Change...jsubject_jsecurity_level.  Suppose  g  is  a  protected  state.  If  g'  ^  g,  then 
g  is  a  function  of  F*  where  /c'(si)  =  fc.  Since  C  is  invariant,  it  is  clear  by  direct  com¬ 
parison  with  the  consolidated  definition  of  security  that  g'  preserves  both  static  and 
dynamic  protection.  Further,  discre liouary  protection  is  preserved  since  5  and  Af  are 
invariant.  Hence  g'  is  a  protected  state,  and  the  primitive  preserves  protection. 

4.2.11  Change..jsi£Jbject^integTi£y^evel.  Suppose  g  is  a  protected  state.  If  q'^q, 
then  g'  is  a  function  of  g’  where  gc'(.Si)  =  l.  Since  F  is  invariant,  it  is  clear  by  direct 
comparison  with  the  consolidated  definition  of  integrity  that  g'  preserves  both  static 
end  dynamic  protection.  Further,  discretionary  protection  is  preserved  since  B  and  M 
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are  invariant.  Hence  q'  is  a  protected  state,  and  the  primitive  preserves  protection. 


4.2.12  Chai%ge^object^security^ievel.  Suppose  qr  is  a  protected  state.  If  g'  9^  g,  then 
q'  is  a  function  of  /'  where  fo'{oj)  —  k.  Static,  dynamic,  and  discretionary  protection 
ai‘e  preserved  by  an  aigument  identical  to  that  used  to  prove  change^subjeci^se- 
cuTiiy_level .  Moreover,  /o  (^d  (o^  )m )  >  ^  each  descendant 

These  hypotheses  hold  bidirectionally  in  the  hierarchy,  since  >  is  transitive, 
and  so  hold  for  ha(oj)  and  hd(oj).  Hence  compatibility  is  preserved  by  Theorem  3,12,  q' 
is  a  protected  state,  and  the  primitive  preserves  protection. 


4.2.13  C/uingre^o(^eci_iniegrity_leveL  Suppose  g  is  a  protected  state.  If  g’  g,  then 
g'  is  a  function  of  G'  where  gQ‘(oj)=-l ,  Static,  dynamic,  and  discretionary  protection 
are  preserved  by  an  argument  identical  to  that  used  to  prove  cha7igs^subject^i7i~ 
tegrity^^level.  Moreover,  go(f^a(^j))^  ^  each  descendant 

^d(^j)m‘  These  hypotheses  hold  bidirectionally  in  the  hierarchy,  and  so  hold  for  fia(oj) 
and  ha(oj).  Hence  compatibility  is  preserved  by  Theorem  3.12,  g'  is  a  protected  state, 
and  the  primitive  preserves  protection. 


4.3  Summary 

To  move  from  the  theoretical  realm  of  our  model  to  the  practical,  we  have 
defined  a  set  of  kernel  functions,  or  operations,  in  terms  of  the  model.  These  opera¬ 
tions  correspond  directly  with  the: set  of  requests  that  a  subject  may  make  of  the  sys¬ 
tem.  and  hence  in  general  should  be  defined  to  provide  whatever  capabilities  are 
deemed  desirable  in  a  particular  environment.  Whereas  the  static  and  dynamic  protec¬ 
tion  policies  of  the  model  are  fixed  and  rigid,  the  specification  of  the  set  of  kernel  func¬ 
tions  is  arbitrary  as  far  as  the  model  is  concerned. 
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The  approach  of  using  a  set  of  kernel  primitives  offers  a  number  of  salient 
advaintages: 

•  A  logical,  modular  structure  is  immediately  imposed  upon  the  set  of  request 
functions. 

•  The  scope  of  investigation  is  bound;  to  easily  manageable  mono-state  transi¬ 
tions.  V 

t  The  general  problem  of  protection  is  reduced  to  considering  the  protection¬ 
preserving  properties  of  single  primitives:  induction  over  all  possible  state 
transitions  then  guarantees  systemic  protection. 

•  Experimental  features  can  be  modelled  and  investigated  concurrently  or 
independently  with  no  additional  complications  to  the  system. 

The  kernel  primitives  specify  sample  algorithms  which  are  suitable  for  imple¬ 
mentation.  Tantamount  to  the  algorithms  are  their  proofs  of  safety,  which  are  based 
on  the  theoretical  foundations  laid  in  the  previous  chapter.  The  proofs  are  of  clear 
importance,  for  a  protection  mechanism  which  does  not  behave  correctly  is  of  dubious 
value.  Moreover,  any  algorithm  which  can  be  shown  to  be  protection-preserving  in  a 
mam:ier  analogous  to  that  used  here  could  be  introduced  into  an  instantiation  of  the 
model  without  compromising  the  system’s  security  or  integrity. 


5.  FURTHER  OPERATING  SYSTEM  CONSIDERATIONS 


There  is  no  difficulty  in  deciding  a  case  —  only  hear  both  sides  patiently, 
then  consider  what  you  think  justice  requiT^s.  and  decide  accordingly: 
but  never  give  your  reasons,  jor  your  jiuigement  will  probably  be  right, 

but  your  reasons  will  certainly  be  wrong. 

—  Lord  Mansfield 

Implementing  a  model  of  computer  protection  will  naturally  give  rise  to  some 
issues  that  perhaps  the  model  does  not  address  explicitly.  An  example  of  this  is  how 
the  model  might  fit  into  the  overall  hardware  scheme  of  a  system.  Are  any  hardware 
modifications  necessary  or  desirable?  If  so,  what  is  the  scope  of  the  modifications,  and 
what  tradeoffs  are  involved? 

This  chapter  addresses  certain  topics  that  help  bridge  the  gap  between  the 
design  of  the  model  and  a  robust,  embellished  implementation.  The  issues  have  not 
been  accidentally  overlooked  until  now;  rather,  most  of  them  aire  of  a  nature  orthogo¬ 
nal  to  the  development  of  the  model  and  hence  would  have  served  only  to  complicate 
earlier  design  questions.  One  topic  that  does  not  admit  to  a  solution  is  introduced,  to 
point  out  certain  physical  and  theoretical  limitations  in  the  general  area  of  computer 
protection.  This  topic  pertains  to  the  use  of  ’’subtle’'  communication  paths  to  leak 
information  between  asynchronous  processes.  The  chapter  concludes  with  a  discussion 
of  how  to  handle  data  backup  and  retrieval  operations  without  compromising  the  secu¬ 
rity  or  integrity  of  the  system.  The  nature  of  the  design  permits  the  operations  to  be 
performed  in  a  non-dedicated  environment,  transparently  to  other  users. 
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5.1  Handling  Internal  Protection  Controls 


A  prerequisite  for  a  secure  computer  system  is  the  absence  of  software  errors 
and  a  minimum  of  hardware  errors  [Chan76].  There  is  a  fundamental  difference 
between  hardware  and  software  reliability,  in  the  sense  that  the  physical  operating 
characteristics  of  a  hardware  component  preclude  completely  error-free  operation. 
Kence,  while  both  the  hardwaLre  and  software  components  of  a  computer  system  are 
susceptible  to  algorithmic  errors,  hardware  components  are  also  susceptible  to  proba- 
balistic  faults. 


To  minify  (or,  more  properly,  eradicate)  software  algorithmic  errors,  program 
proofs  and  certification. techniques  can  be  employed.  We  have  made  use  of  such  tech¬ 
niques  to  demonstrate .  that  our  model  of  computer  protection  functions  as  it  was 
intended  to.  However,  to  be  effective,  the  system  into  which  the  protection  mechanism 
is  being  placed  must  also  be  certified,  at  least  to  the  extent  that  its  operating  system 
kernel  is  verifiably  correct.*  No  protection  mechanism  can  be  reliable  if  the  encom¬ 
passing  environment  is  not  itself  protected. 


Assuming  a  particular  environment  can  be  reasonably  expected  to  support  pro¬ 
tection  controls,  then  one  efiective  way  to  implement  the  model  is  by  means  of  a  refer¬ 
ence  monff or  [Step 74,  Bell75a,  Rhod76].  A  reference  monitor  is  an  abstract  mechanism 
which  mediates  and  decides  the  validity  of  all  access  attempts  by  subjects  to  objects. 
Figure  5-1  rGold78b]  schematically  shows  the  reference  monitor  and  its  relationship  to 
the  active  and  passive  elements  in  the  system.  The  database  is  a  protected  area  in 
which  the  allowability  decision  is  encoded.  This  is  disjoint  from  the  monitor  itself 
because,  in  a  system  which  is  dynamic,  the  database  must  be  alterable.  The  reference 
monitor  machinery,  however,  must  clearly  be  static. 


*  Rusliby  tl^asiiSOj  uiscassces  s.  Vci'iScstioxi  me tiio^ ology  boseci  on  sepsTS-lyle  decoji.pcisition  of  conceptucilly 
distributed  systems.  The  technique  could  prove  to  have  substantial  impact  on  the  verifiability  of 
operating  system  kernels. 
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Figure  5-1.  A  reference  monitor  and  its  associated  environment. 

To  be  a  useful  tool,  a  mechanism  ■which  implements  a  reference  monitor  must 
satisfy  three  logical  properties: 

1.  Completeness.  The  mechanism  must  monitor  and  enforce  all  accesses  of 
objects  by  subjects,  and  must  not  be  circumventable  (see  Figure  5-8). 

2.  Isolation.  The  mechanism  and  its  database  must  not  be  accidentally  or  mali¬ 
ciously  modifiable  by  any  external  operations. 

3.  Correctness.  The  mechanism  must  have  provably  proper  behaviour,  and  must 
faithfully  enforce  the  specified  protection  policies, 

A  specific  set  of  kernel  functions  of  the  model  specifies  the  formal  operation  of 
the  reference  monitor,  and  the  data  entities  which  comprise  the  dynamic  state  of  the 
system  form  the  authorization  database.  Therefore,  the  reference  monitor  must  allow 
subjects  to  access  objects  only  if  permitted  by  its  representation  of  the  model’s  access 
controls.  Further,  the  database  of  the  reference  monitor  must  change  only  as  permit¬ 
ted  by  the  certified  kernel  functions. 
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tlD  SUCH  fHTH  EXISTS 


Figure  5-2.  The  completeness  of  a  reference  monitor. 

The  three  operational  requirements  listed  above,  and  the  obvious  need  for 
efficiency,  dictate  that  the  reference  monitor  be  implemented  as  a  combination  of 
software  and  hardware.  To  be  sure,  pure  software  validation  of  every  access  to  an 
object  by  a  subject  would  add  enormously  to  the  complexity  and  overhead  of  the  refer¬ 
ence  monitor,  and  hence  of  the  system  as  a  whole.  The  amount  worth  implementing  in 
hardware  naturally  depends  upon  the  capabilities  and  limitations  of  the  machine  itself. 
For  example,  the  hardware  architecture  might  permit  access  to  all  objects  in  all 
desired  modes,  so  that  the  hard'ware  access  controls  would  need  to  be  responsible  for 
constraining  access  according  to  the  protection  policies.  However,  complications  to 
this  clear-cut  view  quickly  arise,  because  the  machine  architecture  might  be  such  that 
the  granularity  of  hardware-restricted  accesses  is  insufficient  to  enable  the  protection 
policies  to  be  faithfully  enforced.  Smith  [Smit75]  gives  a  more  complete  treatment  of 
machine  architecture  requirements  for  secure  systems.  The  portion  of  the  reference 
monitor  that  is  implemented  in  softw^are  becomes  the  security  kernel  ilseif. 
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Throughout  this  discussion,  and  the  development  of  the  model,  we  have  chosen 
to  reason  about  the  security  of  a  system  solely  in  terms  of  the  high-level  abstract  view- 
suggested  directly  by  the  model.  Indeed,  the  ability  to  experiment  -with  and  learn 
about  protection  by  examining  abstract  behaviour  was  one  of  the  primary  motives  for 
investigating  models  of  protection.  However,  this  leaves  open  the  question  of  ensuring 
consistency  between  the  high-level  model  and  the  actual  implementation,  a  procedure 
which  begs  as  much  care  and  attention  as  did  the  development  of  the  model  itself. 
Although  beyond  the  scope  of  this  thesis,  we  mention  the  problem  in  recognition  of  the 
fact  that  it  is  an  important  step  in  implementing  a  protected  system.  Burke  [Burk74] 
and  Bell  and  Burke  [Beli75a]  discuss  a  general  solution  to  the  problem  by  demonstrat¬ 
ing  a  behavioural  correspondence  between  successively  less  abstract  representations 
of  a  system,  the  least  abstract  specification  being  the  implementation  itself. 

5.2  Asynchronous  Communication  Channels 

Certain  classes  of  information  flow  are  highly  difficult  or  impossible  for  any 
protection  mechanism  to  control,  even  with  the  most  elaborate  policies.  For  example, 
a  program  can  convey  information  to  an  observer  or  to  another  program  by  (acciden¬ 
tally  or  intentionally)  encoding  it  into  some  physical  phenomenon,  without  actually 
storing  it  into  the  memory  of  the  computer.  The  data  can  then  be  transmitted  incre¬ 
mentally  using  observable  system  characteristics  as  the  code  medium.  Such  informa¬ 
tion  paths  are  known  as  co^fer^  channels  [Lamp73,  Lipn75]. 

A  simple  covert  channel  which  is  difficult  to  seal  off  is  the  execution  time  of  a 
program.  A  program  might  read  a  confidential  value  and  perform  some  operation 
repeatedly  for  a  number  of  times,  proportional  to  the  value.  An  observer  of  the  pro¬ 
gram  can  then  deduce  the  confidential  value  simply  by  measuring  the  running  time,  if 
he  kno-W's  or  can  determine  how  long  the  program  Lakes  when  the  value  is  unity.  Other 
types  of  covert  channels  exploit  program  pow^er  consumption  [Denn79],  page  fault 
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rates,  and  compute-to-I/0  ratios. 

The  only  knovvn  solution  to  the  general  problem  of  covert  channels  requires 
that  the  person  running  a  task  explicitly  state  in  advance  vv’-hat  physical  resources  his 
task  will  use,  and  how  long  it  will  take  [Denn79].  The  requested  resources  are  dedi¬ 
cated  to  the  job,  and  the  results,  even  if  incomplete,  are  returned  to  the  user  at  pre¬ 
cisely  the  time  specified.  The  system  guarantees  that  the  task  will  consume  exactly 
what  resources  the  user  claimed  it  would.  This  strategy  has  a  number  of  obvious 
impractical  consequences,  including  being  prohibitively  expensive.  However,  it  does 
ensure  that  an  observer  can  deduce  nothing  from  the  execution  time  or  resource  utili¬ 
zation  of  a  program  that  he  did  not  know  beforehand;  but  even  then  he  can  perhaps 
deduce  something  from  the  completion  status  of  the  task. 


5.2.1  Indirect  Channels  Through  Cooperating  Processes.  Because  no  adequate  solu¬ 
tion  to  covert  channels  is  know^n,  the  general  problem  vail  not  be  considered  further. 
However,  wc  will  consider  one  specific  indirect  channel  which  the  model  seals  off,  to 
illustrate  the  subtleties  involved. 

Suppose  that  a  subject  with  a  particular  security  level  is  denied  a  request  to 
destroy  an  object  with  the  same  security  level  if  there  is  another  object  with  a  higher 
seourity  level  inferior  to  it  in  the  hierarchy.  The  situation  is  illustrated  in  Figure  5-3, 
for  the  security  levels  '’confidential"  and  "top  secret."  Compatibility  (ignoring  integrity) 
is  not  violated,  since  the  security  level  of  Oi  is  dominated  by  that  of  Og.  and  oi  is 
hierarchically  superior  to  Og.  But  consider  what  can  happen  if  Sg  arbitrarily  creates  or 
destroys  Og-  Then,  the  system’s  response  to  s^’s  request  to  destroy  Lhe  subLree  with 
root  oj  will  be  affected  by  the  instantaneous  existence  of  og  as  designated  by  sg.  sg  is, 
in  effect,  transmitting  one  bit  of  information  to  Sj  (with  whom  it  could  not  otherwise 
communicate)  by  its  decision  to  spawn  og. 
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Figure  5-3.  A  potential  one-bit  communication  cheinnel  between  two  subjects. 

The  design  of  the  delete^object^tree  kernel  function  precludes  the  possibility 
of  this  subversive  communication,  by  not  prohibiting  the  destruction  of  a  subtree  hav¬ 
ing  objects  of  differing  security  or  integrity  levels.  However,  the  insidiousness  of  the 
situation  illustrates  the  complex  interactions  that  must  be  considered  when  designing 
or  extending  a  kernel  function. 
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5.2.2  Indirect  Channels  Through  the  Security  Kernel.  The  security  kernel  itself  can 
in  some  instances  unwittingly  act  as  a  vehicle  for  transmitting  information  between  two 
user  programs,  even  though  it  may  faithfully  preserve  the  desired  protection  proper¬ 
ties.  To  illustrate  this,  consider  the  problem  of  storage  resource  allocation.*  Suppose 
space  for  object  segments  is  allocated  from  a  common  pool  shared  by  users  of 
different  security  and  integrity  levels.  To  further  simplify  the  scenario,  suppose  that 
there  are  only  two  subjects,  Sj  and  Sg,  and  that  there  is  sufficient  room  in  the  system 
for  only  one  new  object. 

Subject  Si  is  given  the  opportunity  to  create  a  new  object  via  cadling 
create_object .  After  this,  a  request  by  subject  Sg  to  create  a  new  object  will  be  granted 
if  and  only  if  si  has  not  previously  made  a  create  request.  The  net  effect  is  similar  to 
that  described  in  the  preceding  section:  Si  can  effectively  send  a  single  bit  of  informa¬ 
tion  to  Sg  by  its  choice  to  call  creat2_object , 

This  particular  problem  could  be  solved  by  assigning  a  space  quota  to  each 
user,  or  to  each  set  of  users  with  the  same  security  aind  integrity  levels,  in  such  a  way 
that  the  total  of  all  such  quotas  does  not  exceed  the  space  available  to  the  system.  The 
denial  of  a  create  request  due  to  resource  exhaustion  can  then  tell  a  user  only  that  his 
quota  is  exhausted,  and  this  information  is  at  his  own  protection  level. 

The  picture  can  get  more  complicated,  however.  Suppose  the  allocation 
scheme  is  modified  to  properly  partition  users  of  different  protection  levels.  Let  Sj  and 
sg  each  have  a  quota  of  one  object,  and  assume  the  system  has  space  for  at  least  two 
objects.  A  protection  threat  still  exists  if  an  object’s  disk  address  or  location  index 
(say  zero  and  one  for  the  first  two  slots)  can  be  determined  by  its  creator.  To  see  this, 
assume  that  the  space  allocation  routine  assigns  the  first  (that  is.  numerically  least) 
free  location  to  a  new  object.  Then,  after  creating  a  new  object,  sg  can  determine 
whether  or  not  Si  has  created  an  object  simply  by  observing  the  value  of  the  location 


•  This  problem  was  originally  pointed  out  by  IfiUen  [Mill75], 
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index  assigned  to  his  new  object. 

At  least  two  ways  to  handle  this  situation  present  themselves.  One  is  to  reserve 
separate  physical  areas  or  locator  tables  for  objects  having  different  protection  levels. 
The  second  method  is  to  make  the. location  index  inaccessible  to  the  user. 

The  interesting  point  about  this  problem  is  that  it  is  really  one  specific  instance 
of  a  much  larger  class  of  protection  threats,  namely  those  where  the  security  kernel 
intentionadly  but  imprudently  transfers  classified  Information  from  its  area  to  that  of 
the  user.  The  general  class  of  problems  can  be  handled  by  insisting  that  the  kernel 
itself  obey  its  protection  properties  when  reading  and  writing  its  own  local  state  vari¬ 
ables.  Figure  5-4  illustrates  a  sample  transmission  path  from  Si  to  sg  via  some  kernel 
parameters  A  and  B ,  and  an  internal  kernel  variable  X .  The  flow  is  clearly  invalid  if  the 
security  level  of  Oj  dominates  that  of  Og,  or  if  the  integrity  level  of  Oj  is  dominated  by 
that  of  0  2-  Observing  static  and  dynamic  protection  ensures  that  the  kernel  can  never 
compromisingly  pass  information  from  one  subject  to  another.  Moreover,  recognizing 
this  property  leads  to  the  immediate  conclusion  that,  if  all  index  locators  are  con¬ 
tained  in  a  single  table*  then  that  table  should  be  inaccessible  to  the  user  because  it 
contains  information  at  arbitrary  protection  levels. 


5.3  System  Backup  and  Retrieves 

System  backup  is  the  periodic  dumping  of  all  data  on  a  system,*  generally  to 
an  on-line  or  off-line  archive,  or  to  magnetic  tape.  A  retrieve  operation  is  a  selective 
recovery  procedure  which  restores  the  on-line  version  of  an  object  to  its  stale  at  the 
time  of  the  backup. 


•  A  variant  of  this,  incre-menial  backup,  dumps  only  those  objects  which  have  changed  since  the  last 
c(»nplete  backup. 
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Figure  5-4.  TrEinsinitting  data  through  the  kernel. 

Backup  and  retrieval  operations  in  any  system  present  some  form  of  potential 
protection  problem,  because  the  utilities  involved  must  be  able  to  access  every  object 
within  the  system.  Usually,  such  utilities  have  formal  access  to  no  objects,  and  instead 
are  implemented  so  that  they  circumvent  the  normal  machinery  which  would  inhibit 
their  reading  or  writing  ability. 

The  backup  and  retrieval  utilities  can  be  handled  by  the  protection  model  in  a 
clean  and  effective  way,  by  making  each  utility  correspond  to  a  pseudo-subject,  and  by 
making  the  data  archive  correspond  to  a  pseudo-object.  Specifically,  the  access 
matrix  M  cem  be  augmented  to  contain  a  row  for  each  of  backup  and  retrieval,  and  a 
column  for  the  archive:  the  backup  procedure  can  be  given  "append"  access  to  the 
archive  and  "read"  access  to  every  other  active  object,  while  the  retrieval  procedure 
can  be  given  "read"  access  to  the  archive  and  "write"  access  to  every  other  object. 
"Write"  access  is  required  because  the  retrieval  process  is  really  a  destructive 
modification  of  an  object  [Groh76].  The  resulting  access  matrix  is  diagrammed  in  Fig¬ 
ure  5-5.  SB,  Sr,  and  refer  to  the  backup  and  retrieval  procedures,  and  the  archive, 
respectively. 
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Figure  5-5.  Handling  backup  and  retrieves  using  an  access  matrix. 

Access  to  the  archive  by  the  backup  and  retrieval  operations  is  static  and  need 
be  set  only  once.  Access  to  the  other  active  objects  can  be  maintained  dynamically  by 
the  kernel  functions.  Alternatively,  it  could  be  temporarily  set  using  some  special 
privileged  mechanism  prior  to  running  either  utility,  but  this  is  clearly  a  less  desirable 
back-door  approach. 

Backup  of  the  system  can  proceed  as  follows.  The  procedure  first  obtains 
access  to  04  via  calling  get^append.  Then,  running  with  the  most  permissive  protec¬ 
tion  levels  (that  is,  the  highest  security  level  and  the  lowest  integrity  level),  sg  secures 
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access  to  each  object  in  the  system  in  turn,  using  the  get^read  kernel  function.  The 
object  is  appended  to  ,  which  is  at  the  same  level  as  Sp.  and  access  to  the  original 
copy  of  the  dumped  data  is  removed  using  delete^read .  Since  sq  is  writing  to  only  one 
object  (namely  Oj ),  there  is  no  difficulty  regarding  accessing  objects  whose  protection 
levels  are  not  dynamically  compatible  with  each  other. 

The  retrieval  process  operates  in  a  dual  fashion.  Running  with  the  lowest  secu¬ 
rity  level  and  the  highest  integrity  level,  sjf  reads  an  object  from  the  archive  (whose 
security  and  integrity  levels  must  be  altered  to  be  compatible  with  those  of  the  pro¬ 
cedure),  and  overwrites  the  appropriate  user  object.  Since  has  ''write”  access  to 
only  one  object  at  a  time,  the  mechanism  does  not  violate  the  rules  of  djmamic  protec¬ 
tion. 

To  handle  the  elevation  and  degradation  of  faioji)  and  170(04)  according  to 
whether  sjj  or  is  running,  04  must  be  placed  immediately  below  the  root  node,  0^,  in 
the  hierarchy,  and  must  be  a  terminal  object.  An  unrestrained  compatible  hierarchy 
requires  that  ojj  have  a  minimal  /o(oi?)  and  a  maximal  P'0  (0^ ).  During  backup,  04  must 
have  a  maximal  /o(o4)  and  a  minimal  PoCoj);  during  retrieval,  the  requirements  sug¬ 
gest  a  minimal  fo{oA)  and  a  maximal  (see  Figure  5-6).  If  there  are  no  objects 

inferior  to  0^4 ,  then  compatibility  is  maintained  whth  either  set  of  security  and  integrity 
levels. 

As  an  additional  consideration,  the  backup  routine  might  want  to  record  the 
security  and  integrity  levels  of  each  object  dumped,  and  its  corresponding  access 
column  in  M.  A  retrieve  could  then  use  this  information  to  reset  the  access  for  the 
restored  object.  The  retrieve  procedure  might  also  want  to  prohibit  retrieving  an 
object  whose  security  or  integrity  level  had  changed  in  the  interim,  since  permitting 
such  an  operation  implies  potentially  disrupting  objects  in  the  hierarchy  in  order  to 


preserve  compatibility. 
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Figure  5-6,  Hierarchical  level  requirements  for  the  backup  and  retrieval  operations. 
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A  salient  advantage  of  having  an  on-line  data  archive  is  that  users  can  request 

that  objects  be  backed  up  or  retrieved  at  their  own  discretion,  or  that  their  data  not  be 

backed  up  at  all.  The  backup  process  running  on  behalf  of  a  particular  user  can  allow 

appending  to  the  archive  any  object  to  which  the  user  has  seme  form  of  access.  The 

retrieval  process  can  restore  any  object  to  which  the  user  has  "write"  access.  (An 

effect  of  this  is  that  a  subject  with  only  "append"  access  to  an  object  cannot  directly 

\ 

recover  it.)  Generations  of  copies  of  objects  can  also  be  maintained  in  the  archive,  so 
that  more  ancient  versions  can  be  restored  if  desired. 


5.4  Summary 

This  chapter  has  addressed  a  number  of  topics  which  become  important  in  the 
certification  and  implementation  phases  of  the  development  of  a  secure  operating  sys¬ 
tem  kernel.  The  discussions  are  by  no  means  exhaustive  of  the  numerous  questions 
which  might  arise.  However,  they  do  highlight  some  key  areas  and  point  out  possible 
solutions  where  answers  are  known. 

The  reference  monitor  concept  offers  a  technological  basis  for  implementing 
protection  controls  whose  effectiveness  can  be  verified.  This  result  provides  the 
needed  framework  to  hold  the  model  in  an  actual  system.  Stepping  from  the  model  to 
an  implementation  can  be  done  incrementally  using  a  formal  design  methodology. 

Covert  channels  remain  an  open  problem  for  which  solutions  to  specific  cases 
may  exist.  Sealing  off  all  such  communication  paths  in  a  system  in  a  cost-effective 
manner  is  probably  not  possible.  Even  though  a  general  solution  is  not  understood,  it 
is  important  that  the  problem  be  identified  and  that  specific  violations  be  precluded 


wherever  it  is  feasible  to  do  so. 


Archiving  objects  on  a  computer  system  can  be  accomplished  directly  within 
the  model,  without  any  special  external  level  of  privilege.  This  makes  it  possible  to 
selectively  or  fully  back  up  the  data  on  a  system  without  compromising  security,  while 
the  system  is  running  in  a  non-dedicated  mode. 


6.  PROTECTION  IN  A  HIGH-LEVEL  ENVIRONMENT 


**The  name  of  the  song  is  called  'Haddocks'  Eyes. 
"Oh,  that's  the  name  of  the  song,  is  it?"  Alice  said,  trying  to  feel  interested. 

"No.  you  don't  understand."  the  Knight  said,  looking  a  little  vexed. 

"That's  what  the  name  is  called. 
The  name  really  is  'The  Aged  Aged  Man. '" 
"Then I  ought  to  have  said  ‘That's  what  the  song  is  called'?" 

Alice  corrected  herself. 
"No,  you  oughtn't:  that's  quite  another  thing! 

The  song  is  called  ‘Ways  and  Means': 
but  that's  only  what  it's  called,  y  oiL  know!" 
"Well,  Vihat  is  the  song,  then?"  sn.id.  Alice, 
who  was  by  this  time  completely  bewildered. 
"/  was  coming  to  that,  "  the  Knight  said. 
"The  song  realty  is  'A-sitting  On  A  Gate': 
and  the  tune’s  my  own  invention  " 

—  Lewis  Carroll 


The  emphasis  in  the  preceding  chapters  cf  this  thesis  has  been  toward  protec¬ 
tion  in  operating  systems.  In  any  computer  protection  issue,  one  is  ultimately  con¬ 
cerned  with  the  ability  to  allow  multiple  users  to  share  the  same  facilities.  At  the  level 
of  the  operating  system,  these  facilities  might  include  physiczd  memory,  datasets,  or 
processes.  Maturally,  the  nature  of  the  protection  controls  is  dependent  upon  the  facil¬ 
ities  themselves.  As  has  been  discussed*  tite  best  way  to  implement  the  multi-level  pol¬ 
icies  that  have  been  presented  is  with  A  IJiixture  of  hardware  and  software.  At  the 
primitive  level  of  the  operating  system,  it  is  possible  to  do  this,  but  as  one  moves 
further  away  from  the  machine  and  closer  to  the  end  user,  this  luxury  does  not  neces¬ 
sarily  follow.  The  facilities  to  be  protected  are  different  and  of  a  higher  level,  and  this 
affects  the  design  and  implementation  methodology  of  suitable  controls. 

This  chapter  introduces  the  problem  of  providing  protection  within  an  interac¬ 
tive,  interpretive  environment,  and  demonstrates  the  relationship  between  this  and  the 
approach  taken  when  designing  the  multi-level  protection  model.  The  purpose  of  the 
investigation  is  twofold:  First,  the  interdependency  of  protection  controls  with  their 
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environment  is  emphasized,  by  considering  a  context  wherein  some  of  the  underlying 
assumptions  behind  operating  system  security  become  invalid  or  irrelevant.  Second, 
the  requirement  for  protection  within  this  class  of  environment  is  espoused,  and  an 
appropriate  protection  mechanism  for  handling  confinement,  mutual  suspicion,  and 
other  classes  of  problems  is  developed. 

Interest  in  this  discussion  will  be  centred  on  the  interactive  language  APL, 
although  many  of  the  concepts  to  be  developed  are  immediately  extensible  to  other 
high-level  environments.  APL  was  originally  developed  by  Iverson  [Iver62]  as  a 
mathematical  notation  for  exposition.*  The  APL  environment  was  chosen  because  the 
language  is  receiving  increasingly  wide  use  in  many  sensitive  business  and  government 
applications,  and  because  the  environment  is  capable  of  completely  shielding  the  user 
from  the  vagaries  of  the  underlying  operating  system.  The  need  for  viable  protection 
controls  within  the  language  exists,  and  the  framework  to  support  it  is  already  in  place. 

To  further  define  the  scope  of  the  discussion,  it  will  be  assumed  that  the  protec¬ 
tion  controls  will  rest  on  top  of  (or,  more  precisely,  be  integrated  in)  the  interpreter  of 
the  APL  system  (see  Figure  1-1).  When  considering  protection  in  operating  systems, 
the  assumption  was  made  that  the  hardware  and  software  below  the  security  kernel 
was  capable  of  correctly  sustaining  the  operation  of  the  kernel.  Here,  too,  it  will  be 
assumed  that  all  machinery  below  the  protection  mechanism  functions  properly  and  in 
an  uncompromising  manner. 


6. 1  Contrasting  Approaches  to  Protection 

Consider  two  computer  programs,  one  running  on  a  system  in  an  appropriate 
low-level  environment  with  an  operating  system  interface,  and  another  running  in 
privileged  supervisor  state  on  a  machine  devoid  of  ancillary  software.  In  the  latter 
case,  the  program’s  environment  is  simply  the  memory  of  the  machine,  and  the 


•  A  full  description  of  an  extended  version  of  APL  can  be  found  in  [Berr79]. 
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available  complement  of  machine  instructions,  including  I/O  commands.  By  contrast, 
the  embellished  environment  probably  offers  less  memory  to  the  running  program 
(with  more  restrictions  on  its  organization),  and  an  instruction  set  in  which  at 
minimum  the  I/O  commands  have  a  different,  more  parameterized  format. 

Now  consider  a  program  executing  in  a  high-level  emdronment  in  which  the 
mere  existence  of  an  operating  system  is  neither  apparent  nof^  important.  Here,  the 
memory  available  to  the  program  is  set  aside  and  managed  by  the  system.  An  auxiliary 
storage  file  operation  specifies  not  a  device,  record,  and  count,  but  rather  a  name  or 
numerical  equivalent  which  the  system  looks  up  in  its  own  tables  and  maps  to  a  device 
address,  automatically  and  unbeknown  to  the  user. 

Since  the  user  surrounded  by  a  high-level  environment  has  different  tools  to 
work  with  and  a  different  perspective  to  work  from,  it  is  not  surprising  that  his  protec¬ 
tion  concerns  might  take  on  a  different  form  from  those  at  a  more  primitive  level. 
Indeed,  the  design  of  high-level  secure  systems  creates  a  category  of  problems 
separate  from  those  examined  with  reference  to  operating  systems.  While  operating 
system  problems  such  as  mutual  suspicion  and  confinement  are  still  very  important 
issues,  their  conceptual  solutions  must  now  fit  into  a  more  abstract  framework  to  be 
suitable. 

Within  the  APL  environment,  it  is  presently  difficult  and  cumbersome  to  write 
secure  softweire.  The  problems  are  related  to  the  interpretive,  interactive  nature  of 
the  language,  as  well  as  to  the  particular  semantics  of  various  language  features  emd 
implementations.  While  writing  a  secure  package  in  APL  is  possible,  it  requires  too 
much  familiarity  with  both  the  language  itself  and  the  particular  implementation  under 


which  it  is  to  run. 
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6.2  Protection  of  Application  Packages  in  APL 

“We  introduce  the  following  definitions. 


Definition.  An  applicaiion  package  is  a  cohesive  collection  of  interacting  func¬ 
tions  and  variables,  some  or  all  of  which  may  be  referencable  by  the  user.  A  pro¬ 
tected  application  package  is  one  in  which  the  security  and  integrity  of  the 

\ 

objects  within  the  package  and  their  interrelations  hips  are  controlled  not  by  the 
user  of  the  software,  but  by  its  creator. 

In  addition  to  functions  and  variables,  the  information  within  a  package  can  be  more 
specific.  It  may  contain  references  to  data  files,  or  possibly  to  ititef  ij,i.eu.iate  results 
computed  and  used  by  the  package.  Often,  these  intermediate  results  are  precisely 
the  objects  which  must  be  protected.  For  example,  consider  a  program  which  l  eads  a 
confidential  directory  from  a  file  and  extracts  from  it  entries  pertinent  to  the  user  who 
called  it.  While  the  entries  for  a  particular  user  might  not  be  sensitive  information  to 
that  user,  the  intermediate  object  that  contained  the  unmassaged  directory  certainly 
is. 


The  foregoing  discussion  suggests  that  a  package’s  information  can  be  subdi¬ 
vided  into  two  logically  disjoint  categories,  consisting  of  visible  and  invisible  informa¬ 
tion.  Visible  information  refers  to:  objects  which  the  user  of  the  package  is  permitted 
to  know  about,  and  possibly  have  access  to  display  or  modify.  These  are  objects  which 
the  creator  of  the  package  specifically  intended  the  user  to  be  able  to  access.  In  an 
insecure  package,  objects  which  the  user  can  access  may  include  improperly  pro¬ 
tected  private  information  as  well.  Invisible  information,  then,  refers  to  anything  else 


that  is  Dart  of  the  oackage,  but  should  be  shielded  from  the  user 


As  ill  our  protcetiOii 


model,  in  order  for  the  security  implications  of  a  package  to  be  non-trmai,  there  must 
be  some  information  that  is  considered  private.  Moreover,  at.  least  one  object  must  be 


visible,  or  else  the  package  will  rema.in  dormant  with  no  way  to  reference  any  of  its 

encapsulated  objects. 
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Applications  must  be  able  to  be  combined,  either  as  black  boxes  or  as  cooperat¬ 
ing  utilities,  with  little  effort  on  the  user’s  part.  Combination  is  typically  manifest  in 
two  different  fashions,  as  illustrated  in  Figure  6-1.  The  first  of  these,  separable  combi¬ 
nation,  involves  disjoint  emdronments  that  are  at  the  same  level  relative  to  the  encom¬ 
passing  workspace.  This  configuration  is  useful  when  the  user  wants  to  be  able  to  exe¬ 
cute  two  application  packsiges  in  an  arbitrary  sequence  withoul;  any  mutual  interfer¬ 
ence.  The  second  form  is  nested  co-mbination,  and  is  typified  by  ha\'ing  an  emdronment 
whose  constituent  objects  include  another,  wholly-contained  environment.  From  the 
user's  point  of  view,  the  internal  nesting  or  dependency  of  packages  is  not  apparent. 
This  is  a  substantial  benefit  of  nested  environments,  for  the  user  need  not  be  con¬ 
cerned  about  bringing  the  lower-level  packages  into  the  workspace  when  he  wishes  to 
use  the  main  one,  or  about  how  they  might  interact  with  each  other  once  there. 
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Figure  6-1.  Separable  and  nested  combination  of  applications  within  a  workspace. 
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6.3  Issues  of  InteractiYe  Protection 

There  are  a  number  of  features  in  APL  which  complicate  the  task  of  writing 
secure  application  packages  in  it.  It  is  not  too  surprising  that  these  features  are  also 
some  of  the  most  powerful  and  useful  features  of  the  language  and  its  envii-onxuent. 
The  problems  stem  from  APL's  inherently  dynamic  and  interactive  nature.  Because 
APL  is  interactive,  a  user  is  able  to  gain  control  over  the  execution  of  a  program  while 
its  local  information  is  still  latent.  This  information  is  often  left  vulnerably  exposed  for 
the  user  to  examine  or  alter.  The  problem  is  exacerbated  by  APL’s  dynamic  nature, 
which  makes  it  possible  to  subversively  modify  information  being  used  by  a  program 
and  then  resume  execution,  frequently  without  the  program’s  being  able  to  detect  the 
change. 

Earlier  work  in  documenting  protection  problems  within  an  APL  environment  is 
reported  in  [Gold78b].  Table  6-1  summarizes  the  significant  classes  of  threats  which 
exist.  The  implications  listed  beside  each  type  of  threat  are  those  attacks  which  the 
threat  leaves  particularly  vulnerable,  and  are  not  intended  to  be  exhaustive.  For 
example,  every  threat  is  to  some  degree  conducive  to  leaking  sensitive  information, 
but  the  last  three  lend  themselves  particularly  well  to  this. 

Penfield  [Penf72]  outlined  four  major  problem  areas  facing  the  designer  of  pro¬ 
tection  mechanisms  intended  to  simplify  writing  .secure  APL  software: 

1.  Display  of  functions  or  data  in  the  package 

2.  Modification  of  the  package 

3.  Unauthorized  use  of  the  package 

4.  Unauthorized  propagation  of  the  package 

The  value  of  a  mechanism  can  be  based  in  part  upon  its  ability  to  cope  with  these  prob¬ 
lems.  Earlier  protection  schemes  [Ryan73,  Puck74,  Gree77]  have  dealt  exclusively  with 
the  fii’sL  two  classes.  The  general  approach  was  to  block  subversive  attacks  by  occlud¬ 
ing  the  user’s  ability  to  reference  workspace  objects  that  were  deemed  sensitive.  While 
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TABLE  6-1.  Protection  threats  in  an  APL  environment. 


Claas  of  Threat 

Description 

Implicatioiis 

Control  of  execution 

Program  intentionally  or 
unintentionally  passes 
control  of  execution  to  the 

user 

Execution  sequence  can 
be  examined:  environment 
and  flow  of  control  can  be 
altered 

System  variables 

Implicit  workspace 
environment  is  altered  by 
changing  variables  which 
interface  with  the  inter¬ 
preter 

Ope^^ation  of  program  can 
be  affected 

Name  and  binding  control 

Neunes  are  eliminated  and 
rebound  as  counterfeit 
objects,  possibly  with 
different  classes  and 
valences 

Sensitive  information  may 
be  revealed;  synchronous 
events  (such  as  errors) 
are  easily  induced,  leading 
to  possible  application  of 
other  threats  through  con¬ 
comitant  vulnerabilities 

Shared  variables 

Execution  of  a  program  is 
monitored  or  altered  by 
sharing  variables  it  uses 
with  an  asynchronous  task 

Sensitive  information  may 
be  revealed  or  altered 

File  system  control 

Opened  files  can  be  closed 
by  the  user 

Synchronous  events  arc 
easily  induced,  leading  to 
possible  application  of 
other  threats  through  con¬ 
comitant  vulnerabilities 

protecting  the  wanton  display  and  modification  of  a  package  are  central  issues, 
Penfield’s  latter  two  points,  unauthorized  use  and  propagation  of  a  package,  are  also  of 
concern.  The  protection  mecheuiism  which  will  be  described  handles  all  four  categories 
of  problems  in  a  logical,  consistent,  and  flexible  manner. 


6.4  Assertive  Handling  of  Asynciiron.ous  Events 

Existing  protection  controls  within  APL  are  described  in  the  appendix  to  this 
thesis.  The  reader  is  advised  to  familiarize  himself  with  these,  as  much  of  what  will  be 
said  about  protection  in  the  remainder  of  this  chapter  assumes  an  understanding  of 
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them.  After  considering  existing  controls,  a  number  of  difficulties  surrounding  the 
•writing  of  secure  application  packages  -within  the  language  become  apparent.  How  can 
a  package,  or  even  a  monolithic  program,  be  assured  of  executing  in  a  controlled 
en'vironment?  Hovr  can  the  creator  of  a  package  limit  access  to  its  internal  subrou¬ 
tines  and  variables?  While  event  trapping  goes  a  long  way  toward  providing  solutions  to 
these  problems,  it  suffers  from  an  a'wkward  and  subtle  sjmdrome  which  is  frequently 
condoned  (usually  accidentally)  by  the  writers  of  sensitive  softxvare.  This  problem  is 
now  described,  and  a  simple  yet  powerful  mechanism  to  combat  it  is  proposed  as  an 
extension  to  existing  systems.  The  mechanism  is  designed  to  complement  the  event 
handling  facilities  provided  by  and  indeed  is  described  in  terms  of  them:  how¬ 

ever,  it  can  eeisily  be  applied  to  a  system  -which  does  not  have  event  handling.  The 
mechanism  is  a  prerequisite  to  the  treatment  of  the  more  general  problems  of 
confinement  and  mutual  suspicion,  and  hence  -will  be  discussed  first. 

6.4.1  Program  Interruption  and  Its  Consequences.  The  ability  to  interrupt  a  pro¬ 
gram,  and  possibly  resume  execution  at  a  later  Lime,  is  an  essential  element  of  an 
interactive  system.  In  APJ»,  the  system  distinguishes  bet-w'aen  several  classes  of  asyn¬ 
chronous  events  which  are  capable  of  preempting  program  execution. 

Pressing  the  BREAK  key  once  on  a  terminal  signals  a  weak  interrupt  which  is 
recognized  prior  to  beginning  the  execution  of  a  line.  Pressing  the  BREAK  key  twice  or 
more  constitutes  a  strong  interrupt  if  the  line  being  executed  has  consumed  more 
than  a  certain  quantum  of  CPU  time  and  both  signals  are  received  before  a  new  line 
has  been  put  into  execution.  Normally,  the  system  would  complete  a  line  and  begin 
another  one  before  the  internal  quantum  expired,  and  hence  the  double  BREAK  would 
effectively  be  transmuted  into  a  weak  interrupt.  A  strong  interrupt,  like  an  error, 
preempts  execution  in  the  middle  of  a  line,  wherever  it  is  detected.  By  contrast,  a 
weak  interrupt  always  takes  effect  at  the  beginning  of  a  line,  possibly  before  the  begin¬ 
ning  of  the  first  line  of  a  program.  This  creates  a  non-trivial  vulnerability  which 
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presently  can  be  solved  only  by  CEirefully  examining  individual  program  topology. 

The  severity  of  the  problem  can  best  be  illustrated  by  an  example.  Figure  6-2 
shows  a  locked  APL  program,  called  QUEUED,  which  returns  a  vector  of  request 
numbers  that  were  submitted  by  the  user  and  are  marked  as  "queued"  in  a  hypotheti¬ 
cal  database.  The  directory  of  the  database  is  kept  in  a  file,  and  the  file  is  passnum- 
bered  with  1618033. 


¥  Z^QUEUED iDIRiUlO \UTRAP 

[1]  UTRAR^' o  0  E  USIGRAL  44pDFi?  o  lOOl  E  -^ULC  «  2001  D  EXIT  o 

[2] 

[3]  -^(pTN^iUNAMESA  .  =  '  444  MASTERFILE  ^)/UNUMS)pL0 

[4]  \20)€nNUMS) \0  »  »444  MASTERFILE^  USTIE  TN ,1618033 

[5]  LO iDIR^UREAD  TN ,  1  1618033  »  HUNT IE  TN 

[6]  Z^l  (  (Z?Ji?[  ;1  ]  =  l+DAJ)AZ?Ji?[  ;  2]<0  )/Z?Ji?[  ;  2] 

¥ 


Figure  6-2.  An  APL  program  with  internal  security  requirements. 


The  program  looks  secure.  However,  it  is  subject  at  minimum  to  the  following  threats: 

•  The  program  can  be  interrupted  before  line  1,  at  which  point  control  will  be 
given  to  the  user  with  the  function  suspended. 

•  The  environment  external  to  the  progreim  can  be  empirically  conditioned  so 
that  the  specification  of  UTRAP  on  the  first  line  fails  due  to  insufficient 
workspace  storage.  This  too  v^dll  leave  the  program  suspended. 

After  either  of  the  above,  with  the  program  suspended  on  the  execution  stack,  the  user 
is  in  a  position  to  do  any  of  the  following: 

•  Resume  execution  at  line  2  (thus  bypassing  the  first  line).  The  program’s 
assumption  that  it  is  operating  in  its  conditioned  environment  w-ith  latent 
traps  set  will  then  be  violated.  Without  the  traps  enabled,  a  weak  interrupt  at 
a  later  point  during  the  execution  of  the  program  might  expose  sensitive 
directory  information. 

•  Share  the  variable  DIR  (which  as  yet  has  no  value)  with  another  task  set  up  to 
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match  the  offer.  The  contents  of  the  directory  will  then  materialize  in  the 
second  task  after  QUEUED  assigns  it  on  line  5. 

•  Rebind  DIR  as  a  local  function,  and  resume  execution  at  line  2.  This  will 
cause  the  assignment  to  it  on  line  5  to  fail  due  to  a  SYNTAX  ERROR.  Then, 
erase  DIR  (enabling  its  later  reassignment),  and  erase  TN .  Rebind  TN  as  a 
local  monadic  function  as  follows: 

s 

V  TN  TN 
Cl]  TN 
7 

Resuming  execution  on  line  5,  where  it  was  preempted,  will  then  cause  the 
program  to  display  the  file  passnumber. 

The  passnumber  is  displayed  because  the  expression  TN ,  1  1618033  is  ambiguous  until 
the  object  class  of  TN  is  established.  The  program  expects  TN  to  be  a  variable,  in 
which  case  the  evaluation  of  the  expression  will  result  in  the  comma  being  interpreted 
dyadic  ally  as  a  catenate  operation,  producing  the  intended  three-element  vector 
result.  But  if  TN  is  a  monadic  function,  the  comma  will  be  interpreted  monadic  ally  as 
a  ravel  operation,  the  result  of  which  will  be  passed  as  the  argument  to  the  function 
TN .  Since  TN  has  been  defined  to  display  its  argument,  it  is  easy  to  see  that  the  user 
can  glean  the  passnumber  to  the  file,  along  with  the  number  of  the  component  involved 
in  the  file  operation  (1  in  this  case).  A  more  complex  redefinition  of  TN  could  easily 
have  been  used,  perhaps  to  print  a  trace  of  all  file  operations  prior  to  performing  them 
[Gold78b]. 

Although  QUEUED  is  locked  and  a  perpetrator  would  not  have  the  benefit  of 
being  able  to  display  it,  the  preceding  threats  are  not  difficult  to  carry  out  withoiU 
knowing  the  internal  organization  or  topology  of  the  function. 
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6.4.2  Environment  Conditioning.  In  analyzing  the  nature  of  the  foregoing  discussion, 
it  is  evident  that  the  problem  is  manifest  by  the  inability  for  a  program  to  ensure  that 
its  environment  is  consonant  with  the  program  author’s  intentions.  To  handle  this 
problem,  a  new  dynamic  construct  called  UEC  is  introduced.  UA6’  (environment  condi¬ 
tion)  is  a  system  shared  variable*  w'hich  lakes  on  a  Boolean  value.  A  QEC  setting  of  1 
implies  that  all  stack  levels  at  which  that  setting  is  latent  are  properlv  conditioned:  a 
setting  of  0  has  the  inverse  meaning.  Attempting  to  assign  a  non-Boolean  value  to  'CEC , 
whether  intentionally  or  inadvertently,  results  in  the  fail-safe  specifinatjon  of  0. 

When  UEC  is  1,  the  system  behaves  exactly  as  it  does  at  present.  When  it  is  0, 
however,  any  error  or  interrupt  is  passed  on  to  the  most  local  (highest)  iexic  level 
which  does  not  have  a  0  setting  of  \}EC ,  or  the  global  level  if  none  exists.  The  user  is 
never  given  control  while  there  is  a  latent  0  value  of  [}EC  an^Tvhere  on  the  stack.  More 
formally,  if  [jEC^  represents  the  powerset  of  PEC  giving  all  stacked  values  proceeding 
from  the  most  local  to  the  global  environment,  then  the  expi  ession  per¬ 

forms  a  reverse  cumulative  scan  which  marks  "with  i's  those  levels  of  the  execution 
stack  that  are  to  be  retained. 

Setting  PEC  to  0  therefore  elicits  behaviour  analogous  to  the  following  PTRAP 
specification: 

UTRAF^^  o  0  1000  C  USIGRAL  ±4pn£’i?  o  2  0  01  D  EXIT  o  5* 


That  is,  all  events  are  propagated  out  of  the  range  of  any  such  latent  PTRAP ,  and  the 
execution  stack  is  cut  back  appropriately. 


The  salient  point  behind  pEC  is  that  its  default  globed  value  is  1  (meaning  that 
the  global  environment  is  ahvays  adequately  conditioned  by  default),  but  its  default 
value  upon  entry  into  a  program  which  localizes  it  is  0;  the  act  of  statically  localizing 
PEC  is  taken  as  an  indication  that  the  program  requires  a  conditioned  environment. 


♦The  system  variable  attribute,  asserted  by  the  fact  that  its  name  begins  vrith  a  quad,  implies  that  the 
variable  is  used  implicitly  by  the  A?L  interpreter.  The  shared  variable  attribute  means  that  it  must 
aiwa^'s  be  demied,  and  Qiat  assigxnnents.  to  the  variable  are  validated  by  the  Lntei'preter  so  that  the  object 
always  contains  a  recooui/able  value  within  its  domain 
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This  means  that  simply  localizing  □£'C  without  even  assigning  it  guarantees  that  the 
system  will  recognize  the  program’s  requirements  for  protection.  Since  this  informa¬ 
tion  is  contained  within  the  static  header  of  the  function,  the  efficacy  of  the  mechan¬ 
ism  does  not  rely  upon  certain  parts  of  the  program  being  executed. 

An  essential  difference  between  UTRAP  and  UEC  is  that  OE'C’s  default  automati¬ 
cally  provides  fail-safe  protection.  DZ’/L^P’s  default  does  not.  aYid  hence  the  variable 
must  be  explicitly  assigned  if  protection  is  required  —  an  assignment  that,  as  already 
shown,  cannot  presently  be  guaranteed  to  succeed. 

Localizing  UEC  in  the  header  of  a  function  and  not  assigning  it  affords  a  simple 
way  to  cause  a  function  to  behave  as  a  primitive,  lliis  is  often  desirable,  but  is  orthogo¬ 
nal  to  the  issue  of  protection.  'QEC  can  also  be  used  to  provide  a  protected  buffer  zone 
in  which  a  program  can  condition  its  environment  (enable  event  traps,  define  a  local 
origin,  and  so  on).  When  its  environment  is  conditioned,  the  program  can  set  ^EC  to  1 
to  indicate  this.  A  typical  example  is  illustrated  in  Figure  6-3. 


V  PASSCEECK^UEC^UIO'.UTRA-P 

[1]  UIO^Q  »  UTRAP^' o  19  c  -^ACCERR  °  0  1000  C  ^ERR  «  2001  D  EXIT  «  5' 

[2]  ^(pDTi?AP)  +  0  EXIT  IF  <UTRAR>  INVALID  FOR  SOME  REASON 

[3]  UEC^l  fi  ENVIRONMENT  NON  SAFELY  CONDITIONED 


Figure  6-3.  Typical  use  of  environment  conditioning. 

Since  QEC  is  a  variable,  its  inherently  dynamic  nature  can  be  put  to  even  more 
elaborate  use.  A  program  can  turn  VEC  on  or  off  at  any  point,  in  accordance  with  its 
concomitant  requirements.  Suspending  a  function  in  a  section  where  UEC  is  off  will 
cause  it  to  react  like  a  primitive,  but  suspending  it  outside  of  such  sections  will  not. 
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Figure  8-4  shows  a  program  which  makes  use  of  UEC  during  a  critical  section 
that  begins  some  way  into  it.  The  program,  called  TRANSMIT ,  files  a  status  report 
entered  by  the  user,  and  also  records  some  ancillary  information  in  a  directory.  Prior 
to  the  sensitive  section  of  code,  TRANSMIT  collects  the  message  text  from  the  user.  It 
is  unnecessary  for  this  to  be  performed  in  a  strict*  environment,  and  in  fact  preferable 
that  it  is  not:  if  UEC  were  0  during  text  collection,  then  any  asynchronous  interrupt 
(including  a  communications  line  drop)  would  cut  back  the  stack,  thus  losing  any  text 
that  the  user  had  entered.  On  the  other  hand,  this  behaviour  is  very  desirable  during 
the  update  section  of  TRANSMIT ,  where  permitting  execution  to  be  interrupted  and 
resumed  would  destroy  the  extant  file  interlock.  Although  one  can  sometimes  hcindle 
this  problem  by  placing  critical  sections  in  subroutines,  there  Eire  often  overriding  rea¬ 
sons  why  the  program  must  be  self-contained. 


V  TRAIi SUIT  \  INF  \  TXT  %SIZE  \  UEC  \  UI0 

[1]  fl  LOGS  A  STATUS  MESSAGE  FOR  PERUSAL  BY  TEE  SYSTEM  STEWARD. 

[2]  fi  TEE  SYSTEM  FILE  IS  ASSUMED  TO  BE  TIED  TO  TEE  GLOBAL  VARIABLE 

[3]  ft  <TIE>. 

[4]  fl 

[5]  fl  OTEER  GLOBALS:  V  -  CRi  F  -  TAD 

[6]  fl 

[7]  UEC^UIO^I  fl  ENVIRONMENT  REQUIRES  NO  SPECIAL  CONDITIONING  YET 

[8]  ^TEXTi'  »  TXT^' '  n  PREPARE  FOR  TEXT  COLLECTION  LOOP 

[9]  MOREi^i'  '  ^  .^INP^V\)qDONE  a  STOP  ON  <CR>  OR  <SPACE,CR> 

[10]  TXT^TXT  ,INP  ,CR  »  -^MORE  fl  ACCUMULATE  LAST  INPUT  LINE 

[11]  DONE  :TXT<-^  STATUS  MESSAGE  AS  OF  '.(TAP  UTS )  ,CR,  CR,TXT 

[12]  UEC^O  fl  CRITICAL  SECTION  STARTS  EERE , . . 

[13]  ->(  </2  45IZ£’-HD5IZF  TIE)qSPACEOK  fl  ENSURE  ADEQUATE  SPACE  IN  FILE 

[14]  (  5  00  0  0+5IZS’[3  ] )  URESIZE  TIE  p  IF  NOT,  RESIZE  BY  GENEROUS  AMOUNT 

[15]  SPACEOKiUFEOLD  TIE  p  OBTAIN  FILE  BOLD  FOR  COMING  WRITES 

[16]  TXT  UAPPEND  TIE  p  APPEND  STATUS  REPORT  TO  SYSTEM  FILE 

[17]  ((□i?£’AP  TIE, S), 111  (l+DAJ)  ,lpDi?P^5)  UREPLACE  TIE, 5  p  AUGMENT 
DIRECTORY  WITE  OUR  ACCOUNT  NUMBER  AND  T AS KID 

[18]  UFEOLD  »'  K  'STATUS  REPORT  FILED'  p  RELEASE  EOLD  BEFORE  EXITING 

V 


Figure  6-4.  Delimiting  program  critical  sections  using  environment  conditioning. 
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The  dynamic  nature  of  UEC  also  permits  it  to  be  set  based  on  the  result  of  some 
computation.  For  example,  the  fallowing  statement  will  mark  the  environment  condi¬ 
tioned  only  if  the  user  executing  the  program  is  in  a  list  of  trusted  users: 

Cl ]  UEC^{l\UAI)eTRUSTEDUSERS 


6.4.3  Implications  on  Event  Trapping.  The  final  aspect  of  UEC  that  merits  discussion 
is  its  interaction  with  UTRAP ,  Two  possible  interpretations  present  themselves.  The 
first  is  simply  to  ignore  event  traps  if  the  environment  is  not  conditioned  —  that  is, 
setting  UEC  to  0  precludes  the  use  of  UTRAP  at  that  stack  level  or  any  other  superior 
to  it.  While  this  has  the  advsuitage  of  being  straightforward,  it  robs  environment  condi¬ 
tioning  of  some  of  its  potential  utility.  For  example,  if  a  program  had  an  event  trap  set 
for  FILE  FULL^  then  it  would  not  be  able  to  use  G^C,  for  this  would  cause  the  antici¬ 
pated  error  to  abort  the  program  rather  than  trigger  the  trap.  A  less  orthodox 
approach  suggests  a  well-defined  cooperative  interaction  between  environment  condi¬ 
tioning  eind  event  traps.  Such  a  scheme  is  now  presented. 

When  an  event  occurs  at  a  particular  stack  level,  the  value  of  UTRAP  bound  to 
that  lexic  level  is  examined  first.  If  UTRAP  is  not  localized  or  does  not  handle  the 
error,  then  UEC  is  examined  and,  if  0,  the  top  lexic  level  of  the  stack  is  pared  back.  If 
it  is  1,  the  seELTch  continues  in  an  analogous  fashion  through  the  stack  until  one  of  the 
following  conditions  occurs: 

1.  A  latent  UTRAP  to  handle  the  event  is  encountered,  in  which  case  the  handler 
is  given  control.* 

2.  The  most  global  0  setting  of  UEC  is  reached,  in  which  case  the  stack  is  cut 
back  up  to  and  including  that  lexic  level. 

Even  if  an  event  trap  is  taken,  the  user  is  never  given  control  in  immediate-execution 

•  The  ability  for  a  trap  expression  to  be  given  conti  ol  may  be  overridden  by  means  of  an  earlier  use  of  the 
"S"  (stop)  action  code,  -which  prevents  the  event  from  being  passed  any  further  down  the  stack,  hi  this 
case,  the  destacking  termination  condition  is  2  only. 
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mode  if  there  is  a  latent  unconditioned  emdronment  anwhere  on  the  stack. 

A  simple  example  showing  the  effect  of  these  rules  is  illustrated  in  Figure  6-5. 
Note  that  even  though  COVERFN  and  SUDFN  have  traps  set  for  DOMAIN  ERROR 
(event  11),  COVERFN's  trap  for  that  particular  event  will  never  be  taken  if  that  error 
occurs  in  SUBFN. 


V  COVERFN  EXPRiUEC lUTRAP 

[1]  UTRAP^^o  0  C  ^  ^HANDLED  BY  <COVERFN>  ^  ^  ^  «  SUBFN 

V 


V  SUBFN lUECiUTRAP 

[1]  UTRAP^^ o  11  5 »  fl  DON^T  PROPAGATE  DOMAIN  ERRORS 
[  2  ]  S.EXPR 

V 


COVERFN  fl  CAUSES  A  'SYNTAX  ERROR' 

HANDLED  BY  <COVERFN> 


COVERFN  »v0»  fl  CAUSES  A  'DOMAIN  ERROR' 
DOMAIN  ERROR 

COVERFN  »v0» 

A 


Figure  6-5.  Interaction  of  environment  conditioning  eind  event  handling. 


Fragments  from  a  sample  payroll  application  which  uses  the  cooperation  of  UEC  and 
UTRAP  are  shown  in  Figure  6-6. 


6.5  Namesnaces 

M, 

Confinement  and  mutual  suspicion  are  more  complex  to  handle  than  asyn¬ 
chronous  events,  because  they  involve  interactions  between  communicating  processes 
as  well  as  interactions  between  a  process  and  a  user.  Primitive  environment  condition¬ 
ing  is  therefore  just  a  stepping  stone  toward  overall  application  package  protection.  To 
protect  an  application  package  as  an  entity,  the  concept  of  namespaces  is  introduced. 
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V  PAYROLL \UEC \UTRAPi , 
[1]  UEC^l 


•  • 

[14]  UTRAP^' o  21  E  -^FFULL^  p  TRAP  FOR  ^FILE  FULL' 

[15]  UEC^Q  p  ENTERING  CRITICAL  UPDATE  SECTION 

[16]  NAMES  UAPPEND  TN^l 

[17]  SALARIES  UAPPEND  TN^2 

[18]  MOG  p  LOG  COMPLETION  OF  TRANSACTION 

[19]  UEC^l  »  'UPDATE  COMPLETE'  »  -^TOP 


•  • 

[27]  FFi/LL  :(  50000+1  p24D5'JZE  TN)  URESIZE  TN  P  INCREASE  RESERVATION 

[28]  LN^UER\_2\'\  »  DLM^LNe  '  I']'  »  MSK^^\DLM 

[29]  -^i.{DLM<MSK>y\DLM>MSK) /LN  p  RETRY  FAILING  OPERATION 


V 


Figure  8-8.  An  application  using  environment  conditioning  and  event  handling. 


Definition.  A  naTnespace  is  an  encapsulated  (possibly  empty)  collection  of 
objects,  which  may  include  functions,  variables,  or  other  namespaces.  Each 
namespace  contains  its  own  execution  environment,  which  includes  system 
parameters  specifying  the  referent  index  origin,  comparison  tolerance,  and  so 
on.  It  also  possesses  a  symbol  table  and  an  access  control  matrix,  which  set  the 
profile  of  the  namespace  by  specifying  permissible  interactions  between  those 
objects  which  are  internal  to  the  namespace  and  those  which  are  external. 

Namespaces  therefore  achieve  the  following  desirable  ends: 

•  Permit  an  application  package  to  be  enclosed  and  identified 

•  Provide  an  execution  environment  independent  of  the  global  one,  thereby 
permitting  application  packages  to  be  combined  in  a  controlled  manner 

•  Give  the  creator  of  a  package  precise  control  over  who  can  use,  display, 
modify,  or  propagate  the  package 
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Like  an  APL  program,  a  namespace  must  be  in  a  ’workspace  if  it  is  active, 
although  it  may  be  stored  on  a  file.  A  namespace  is  different  from  a  workspace,  ho’w- 
©■ver,  for  although  it  contains  an  execution  environment,  it  contains  no  execution  stack; 
moreover,  the  symbol  table  of  the  namespace  augments  the  symbol  table  of  the  active 
■workspace  in  a  manner  to  be  described,  and  does  not  supersede  it. 

\ 

6.5.1  Environments  and  Names.  The  eTwironment,  or  context  of  a  namespace  embo¬ 
dies  the  formal  execution  environment  parameters  and  the  objects  that  the  namespace 
may  reference  (both  internal  and  external  to  it).  Each  namespace  therefore  has  a 
separate  en'vironment.  In  fact,  each  copy  of  a  namespace  possesses  its  own  environ¬ 
ment.  In  present  APL  systems,  the  only  environment  in  which  objects  may  be  refer¬ 
enced  is  the  workspace  environment.  Program  execution  may  occur  in  only  one 
environment  at  a  time.  At  any  given  instant,  the  context  to  which  execution  is  bound  is 
said  to  be  active. 

Each  name  has  some  home  context  to  which  it  is  associated.  A  name  denned 
statically  or  dynamically  within  a  namespace  is  bound  to  that  namespace,  although  it 
may  be  referenced  externally  if  it  is  visible.  A  name  is  said  to  be  global  "with  respect  to 
a  context  if  it  is  an  "own  name"  [Kuti67]  of  that  context;  that  is,  if  it  exists  in  the 
environment  •when  no  programs  are  suspended. 

Within  a  given  namespace,  as  within  a  pecrticular  workspace,  all  identifier  names 
must  be  unique.  However,  the  same  name  may  exist  in  several  namespaces,  as  well  as 
in  the  active  workspace.  Normally,  name  conflicts  emanating  from  the  active  environ¬ 
ment  are  resolved  as  follows:  Names  bound  to  the  active  environment  are  examined  for 
a  match.  If  none  is  found,  then  all  other  environments  (including  the  workspace  if  it 
was  not  the  active  en’vironment)  are  checked  for  a  unique  match.  If  this  search  results 
in  no  matches  or  in  more  thsin  one,  then  a  BINDING  ERROR  is  reported,  otherwise,  the 
object  has  been  uniquely  identified. 
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Figure  6-10.  Encapsulating  a  production  application  package. 

The  simplicity  of  the  example  illustrates  the  power  of  the  neimespace  mechan¬ 
ism.  A  set  of  dependent,  unprotected,  cooperating  programs  can  be  encapsulated  in  a 
manner  substantiating  mutually  suspicious  interaction  with  minimal  user  effort  or 
knowledge.  The  only  a.  priori  protection  requirement  is  that  each  isolated  program 
appropriately  condition  its  environment  (using  Q£’C  and  GTViLAP)  where  this  is  desirable 
or  necessary.  UEC  guarantees  that  this  conditioning  is  possible,  and  straightforward  to 


achieve. 
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6.6  Siunmarj 

High-level  computing  environments  give  rise  to  classes  of  protection  threats 
which  are  foreign  to  an  analysis  of  operating  system  protection.  WhUe  a  number  of  pro¬ 
tection  control  concepts  are  universal  and  translate  directly,  the  approach  to  imple¬ 
menting  them  is  quite  different  because  the  tools  provided  by  the  environments  are 
inherently  related  to  the  environments  themselves. 

APL  provides  a  language  framework  which  is  both  interesting  and  practical  for 
considering  high-level  protection.  Approaches  to  providing  protection  in  different 
environments  were  contrasted,  and  threats  in  APL  were  identified.  As  a  basis  for  dis¬ 
cussing  protection  within  the  language,  the  notion  of  an  application  package  as  a 
cohesive  entity  was  formalized.  Application  packages  exhibit  all  of  the  properties  of 
complex,  interacting  computer  utilities,  and  hence  serve  as  a  useful  object  for  the  con¬ 
sideration  of  protection  mechainism  design  questions. 

Asynchronous  events,  in  particular  interrupts,  form  a  serious  class  of  protec¬ 
tion  threat  which  was  solved  with  the  introduction  of  a  dynamic  environment  condition¬ 
ing  parameter.  Handling  of  asynchronous  events  made  it  possible  to  introduce  a  new 
protection  mechanism,  namespaces,  which  could  cope  with  the  problems  of  general 
application  package  protection.  Namespaces  are  ein  encapsulation  facility  which  per¬ 
mit  the  precise  specification  of  the  complete  external  profile  of  a  package,  Including 
what  interactions  the  objects  within  the  namespace  are  allowed  to  participate  in. 
Namespaces  are  controlled  by  means  of  five  new  primitive  system  functions,  which  per¬ 
mit  the  specification  of  ten  different  classes  of  requests^,  emd  one  system  variable.  The 
mechanism  is  almost  syllogistic  in  appearance,  for  it  is  capable  of  handling 
confinement,  sharing,  mutual  suspicion,  display  and  dissemination  of  sensitive  informa¬ 
tion,  as  well  as  other  key  aspects  of  protection.  Moreover,  while  namespaces  fit  very 
well  into  the  APL  language,  the  concepts  espoused  have  direct  applicability  to  other 


environments  as  welL 


7.  CONCLUSIONS 


Nothing  is  so  hurdensome  as  a  secret. 

—  French  Proverb 

\ 

Only  in  growth,  reform,  and  change,  paradoxically  enough, 

is  true  security  to  be  found. 

—  Anne  Morrow  Lindbergh 

This  thesis  has  addressed  the  problem  of  designing  viable  protection  mechan¬ 
isms  for  computer  utilities,  to  allow  the  controlled  sharing  of  programs  and  data 
among  users'  cooperating  in  certain  environments  of  a  system.  The  mechanisms 
described  are  practical  structures  which,  if  implemented,  would  provide  flexible  and 
effective  control  over  the  dissemination  and  alteration  of  data  in  an  operational  com¬ 
puter  utility.  In  this  chapter,  we  summarize  the  work  presented,  point  out  certain  limi¬ 
tations  in  the  mechanisms,  and  suggest  areas  for  further  research.: 

7.1  Summary 

The  design  of  protection ;  controls  is  very  heavily  influenced  by  the  environ¬ 
ment  in  which  they  are  to  exist,  v  This  makes  sense  intuitively,  for  the  objects  over 
which  a  protection  mechanism  is  to  mediate  access  and  the  tools  available  to  it  in 
achieving  that  end,  are  directly  related  to  the  concomitant  environment  of  the  interac¬ 
tion.  The  effect  of  this  in  practical  terms  is  that  mechanisms  which  protect  low-level 
interactions  may  deal  with  more  primitive  concepts  (such  as  password  protection  on 
physical  datasets)  and  may  reasonably  be  expected  to  have  a  high  degree  of  cog¬ 
nizance  of  and  dependence  on.  the;  machine  hardware;  mechanisms  that  protect  high- 
level  environments  may  deal  with  abstract  entities  and  may  be  manifest  in  terms  of 
language  constructs  which  embody  internal  data  structures  sufficient  to  represent  the 
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desired  protection  policies. 

A  clear  distinction  between  the  dissemination  and  the  modification  of  informa¬ 
tion  has  been  espoused  in  this  work.  The  dissemination  of  information  is  a  security 
issue.  The  modification  and  possible  contamination  of  information  is  an  integrity  issue. 
Integrity  by  itself  speaks  nothing  of  the  absolute  behaviour  of  systems.  For  instance,  a 
subsystem  possesses  the  property  of  integrity  if  it  can  be  demonstrated  that  it  adheres 
to  a  well-defined  standard;  no  a  priori  statement  about  the  standard  or  its  correctness 
are  relevant.  It  is  the  function  of  integrity  mechanisms  to  ensure  that  this  standard  is 
continually  satisfied  throughout  the  dynamic  operation  of  a  system. 

Two  protection  mechanisms  for  specifying  and  enforcing  the  access  of  execut¬ 
ing  programs  to  objects  within  the  system  have  been  developed.  The  first  mechanism 
is  a  formal  mathematical  model  which  abstracts  the  basic  requirements  for  multi-level 
military  security.  The  multi-level  structure  of  military  security  arises  from  the  recog¬ 
nition  that  some  information  in  a  utility  is  necessarily  more  sensitive  than  others. 
Classifying  it  as  such  has  two  salient  advantages.  First,  the  level  attached  to  the  infor¬ 
mation  can  be  related  to  the  level  of  an  individual  attempting  to  access  the  data,  in 
order  to  determine  if  the  access  is  authorized.  Such  checks  can  be  enforced  automati¬ 
cally  via  protection  controls  which  implement  the  relation  policies.  Second,  the  infor¬ 
mation  is  explicitly  tagged  with  its  sensitivity,  so  that  authorized  personnel  coming  into 
contact  with  it  are  immediately  aware  of  its  perceived  impact  on  national  security.  To 
handle  the  controlled  dissemination  of  sensitive  information,  each  individual  is  given  a 
clearance  level  which  indicates  that  certain  formal  procedures  and  investigations  have 
been  carried  out  on  that  person,  and  that  the  individual  may  be  trusted  with  informa¬ 
tion  of  a  sensitivity  up  to  and  including  his  clearance.  In  addition  to  sensitivity  levels, 
information  relating  to  specific  subject  eireas  may  be  formally  designated  as  belonging 
to  such  by  means  of  a  category  set,  which  qualifies  the  sensitivity  level  of  an  individual 
or  a  piece  of  information. 
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The  smaller  the  number  of  people  who  share  a  secret,  the  easier  it  is  to  control 
the  further  dissemination  of  that  secret.  In  recognition  of  this,  and  of  the  fact  that  few 
individuals  need  to  be  aware  of  all  of  the  information  classified  at  a  given  sensitivity 
level,  a  finer  grain  of  classification  known  as  need-to-know  is  embodied  in  military  secu¬ 
rity.  The  general  principle  is  that  information  should  not  be  entrusted  to  an  individual 
unless  he  has  both  the  necessary  clearance  (in  terms  of  his  sensitivity  levei  and 

N 

category  set),  and  the  specific  requirement  to  know  the  information.  Whereas  sensi¬ 
tivity  levels  and  category  sets  are  tangible  and  can  be  enforced  through  mandatory, 
objective  mechanisms,  need-to-know  caveats  controlling  the  dissemination  of  informa¬ 
tion  of  a  given  levei  to  individuals  who  possess  the  mandatory  clearances  for  that  level 
are  of  a  subjective,  discretionary  nature. 

At  the  outset,  it  was  recognized  that  executing  programs,  which  are  really  sur¬ 
rogates  for  users,  form  the  active  agents,  or  subjects,  of  a  computer  system;  those 
entities  which  are  manipulated  by  subjects  form  the  passive  repositories,  or  objects. 
Beginning  with  this  logical  formulation,  the  multi-icvcl  model  was  developed  to  embody 
clearances  and  category  sets,  mandatory  and  discretionary  access  controls,  and  a 
structured  hierarchy  representing  the  organization  of  objects  within  the  system. 
Together,  this  information  was  manifest  in  terms  of  an  internal  state  descriptor  which 
specified  the  static  properties  of  a  d)mamic  system  at  a  particular  instant. 

Mandatory  and  discretionary  protection  policies  sufficient  to  embody  the 
requirements  for  military  security  were  developed  for  inclusion  in  the  model.  Manda¬ 
tory  policies  were  subdivided  into  two  classes,  static  and  dynamic,  and  then  into  two 
further  classes  controlling  the  security  and  integrity  of  data.  Sialic  policies  prolecl 
data  from  unauthorized  access  by  stipulating  that,  for  certain  classes  of  access,  the 
security  or  integrity  level  of  a  subject  must  dominate  that  of  the  object  being  manipu¬ 
lated.  This  is  sufficient  to  describe  direct  threats  involving  a  single  object.  Dynamic 
flows  block  the  indirect  subversive  flow  of  information  from  one  object  to  another  via  a 
controlling  subject,  as  might  occur  with  a  Trojan  Horse.  They  function  in  essence  by 
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relating  the  levels  at  which  a  subject  can  observe  all  objects,  to  those  at  which  it  can 
modify  them.  A  set  of  necessary  and  sufficient  conditions  for  the  preservation  of 
dynamic  protection  was  developed  from  this.  The  conditions  recognize  that  if  a  subject 
can  modify  more  than  one  object,  then  the  security  or  integrity  levels  at  which 
modification  is  permitted  must  be  the  same  for  all  objects.  This  level  was  termed  the 
current  security  or  integrity  level  of  the  subject. 

\ 

The  properties  of  the  model  were  analyzed  formally  by  proving  a  number  of  pro¬ 
tection  theorems.  The  theorems  demonstrated  the  conditions  under  which  safety  in  a 
system  could  be  maintained  over  an  arbitrary  sequence  of  dynamic  operations.  Induc¬ 
tively,  the  preservation  of  protection  from  any  state  initially  known  to  be  safe  to  any 
other  state  guarantees  total  systemic  protection.  The  isolation  ot  mono-state  transi¬ 
tions  was  established  rigorously  using  the  concept  of  primitive  requests  made  to  the 
model  on  behalf  of  a  subject.  The  model  provides  the  guidance  f  or  defining  such 
requests,  but  the  actual  semantics  of  them  may  be  tailored  to  the  exigencies  of  the 
system  on  which  the  model  is  to  be  applied.  ■  A  sample  set  of  primitive  operations  was 
developed,  and  proofs  of  safety  based  on  the  results  of  the  protection  theorems  w^^ere. 
presented  to  support  the  contention  that  the  request  functions  behave  in  a  manner 
consistent  with  their  formulation. 


The  approach  of  using  a  well-defined  set  of  primitive  operations  brings  the 
theory  of  the  model  significantly  closer  to  the  implementation  level,  as  well  as  greatly 
simplifying  the  tasks  of  analyzing  the  behaviour  of  a  system  and  modelling  nevr 
features.  To  achieve  the  necessary  degree  of  efficiency  and  flexibility  required  for  a 
production  system,  an  actual  implementation  of  the  model  and  its  policies  suggests  the 
use  of  a  software  security  kernel  with  a  hardware  assist.  Most  of  the  controls  can  be 
realized  in  the  security  kernel,  but  the  machinery  to  mediate  subject-object  interac¬ 
tions  can  be  anticipated  to  require  processor  speeds  achievable  only  with  hard'-varc. 
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The  second  protection  mechanism  in  this  thesis  addressed  the  enforcement  of 

control  in  a  high-level  language  environment,  for  which  APL  was  used  to  exemplify 

important  issues.  Two  basic  problems  were  identified.  First,  mechanisms  to  enable  a 

single,  logically  autonomous  program  to  guarantee  its  execution  in  an  environment 

whose  properties  are  specified  by  the  program  author  and  not  by  the  user  were 

required.  To  meet  this  requirement,  an  environment  conditioning  parameter  called 

\ 

X}EC  was  defined  and  demonstrated  to  be  useful  in  solving  a  number  of  practical  prob¬ 
lems.  The  utility  of  UEC  extends  beyond  simple  environment  conditioning,  due  to  the 
natural  and  useful  manner  in  which.it  interacts  with  event  handling  mechanisms. 

UEC  was  considered  a  stepping-stone  to  the  second  and  central  issue  of  interest 
in  high-level  protection:  mechanisms  to  allow  the  controlled  sharing  of  user-defined 
protected  subsystems.  The  thrust  of  the  problem  is  to  permit  a  collection  of  applica¬ 
tion  programs  and  data  to  be  encapsulated  so  that  only  certain  entities  are  available 
for  manipulation  by  subjects  external  to  the  application,  and  so  that  the  nature  of  per¬ 
missible  manipulations  is  controlled  wholly  by  mechanisms  internal  to  the  protected 
application.  The  ability  to  define  and  share  such  protected  subsystems  permits  users 
to  specify  complex  access  controls  for  sensitive  data,,  share  proprietary  algorithms 
without  divulging  their  operation,  combine  applications  without  regard  for  their  inter¬ 
nal  structure;  and  limit  the  propagation  of  a  package  through  instantiations. 

A  unique  aspect  of  the  mechanisms  which  support  protected  subsystems  is  the 
efficient,  logicaL  and  fiexible  manner  in  which  sharing  is  specified  emd  enforced.  The 
principal  concept  is  that  of  a  namespace,  an  ^encapsulated  package  which  contains  not 
only  application  programs  and  data,  but  also  policy  control  information  in  the'  form  of  a 
S3rmbol  table  and  an  access  matrix.  A  namespace  also  contains  an  execution  enshron- 
ment,  so  that  programs  executing  in  it  may  do  so  in  a  domain  logically  segregated  from 
the  workspace  euid  any  other  namespaces.  A  series  of  primitive  operations  on 
namespaces  permits  the  user  to  specify  the  precise  internal  composition  of  a 
namespace,  and  its  profile  to  external  manipulations  —  in  particular,  the  nature  and 
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degree  of  sharing  in  which  it  may  participate^; 

Taken  together,  environment  conditioning  and  neimespaces  extend  the  funda¬ 
mental  idea  of  programming  generality  by  encouraging  the  use  of  not  just  programs, 
but  entire  protected  applications  as  building  blocks  when  designing  systems.  Indepen¬ 
dently  defined  applications  may  be  combined  in  different  ways  to  participate  in  mutu¬ 
ally  suspicious  computations  without  modifying  the  application'^.  The  efficient  and 
natural  way  in  which  cooperation  is  specified  typifies  the  power  of  these  mechanisms, 
which  provide  not  only  a  general  protection  rtool,  but  also  the  impetus  for  users  of  a 
computer  utility  to  communicate  and  build  upon  one  another's  work  even  when  sensi¬ 
tive  or  proprietary  algorithms  are  involvecL 


7.2  limitations 

This  work  is  not  without  certain  limitations.  The  multi-level  model  is  at 
present  incapable  of  handling  what  may  be  termed  aggregational  data  threats,  which 
are  manifest  as  follows.  The  level  of  classification  of  a  document  is  usuedly  that  of  the 
most  classified  information  contained  wiliiin  it.  In  some  cases,  however,  a  collection  of 
information,  each  component  of  which  is  by  itself  unclassified  (or  classified  at  a  low- 
level),  may  yield  a  synergistic  document  of  higher  classification.  Detecting  such  aggre- 
gationai  threats  requires  consideration  of  the  history  of  the  transitive  closure  ot  data 
flows  in  a  system,  and  not  just  the  dynamics  of  isolated  interactions. 

It  is  possible  that  the  regulatory  controls  in  the  multi-level  model,  notably  the 
integrity  policies,  are  too  restrictive.  Present  integrity  policies  prohibit  the  reading  of 
all  information  at  a  lower  integrity  level  than  the  subject  performing  the  operation.  In 
practice,  this  may  prove  to  be  too  strong  a  principle,  particularly  since  the  potential 
contamination  of  data  is  an  issue  only  if  subsequent  writing  is  performed.  Although  the 
dual  of  this  policy  advocated  for  security  controls  is  adequate  (and  believed  required), 
it  is  possible;  that  the  integrity  attributes  of  a  would-be  reader  of  information  might 
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better  be  diluted  upon  the  arrival  of  less  sound  data,  rather  than  the  operation  being 
prohibited. 


The  high-level  protection  model  covers  ail  known  critical  section  and  name- 
related  threats.  However,  although  more  an  is.sue  of  programming  discipline,  the 
mechanisms  do  not  attempt  to  address  problems  arising  when  a  program  handling  sen¬ 
sitive  information  not  in  a  critical  section  delineated  by  DEC ,  is  coerced  into  perform¬ 
ing  an  action  which  it  was  not  directly  intended  to  by  means  other  than  name  rebind¬ 
ing.  The  simplest  illustration  of  such  a  scenario  is  an  encapsulated  program  which  uses 
the  same  invisible  variable  to  hold  (at  different  times)  both  sensitive  data  and  data  to 
be  output  at  the  terminaL  Normally,  the  program  understands  the  instantaneous 
semantics  of  the  variable  based  on  the  routine's  topology  and  a  knowledge  of  where 
execution  is  taking  place.  Since  the  variable  is  invisibie,  it  cannot  be  altered  by  opera¬ 
tions  outside  of  the  namespace.  However,  an  external  interrupt  may,  if  DEC  has  not 
been  employed,  permit  the  control  of  execution  of  the  program  to  be  transferred  to  a 
different  area  of  the  routine,  where  the  variable  is  assumed  to  contain  insensitive  data 
and  is  used  as  part  of  an  output  expression;  This  is  more  a  programming  discipline- 
ethic  because  DEC  should  perhaps  have  been  used  to  mark  the  critical  section,  and 
different  variable  names  for  the  sensitive  and  insensitive  data  should  definitely  have 
been  used.  It  is  possible  to  detect  the  existence  of  this  form  of  threat  programmati¬ 
cally  if  the  names  of  variables  which  ever  contain  sensitive  information  are  known,  by 
performing  a  dynamic  flow  analysis  of  the  routines  involved  [Gold79]. 


7.3  Further  Research 

Work  on  the  protection  mechanisms  promulgated  in  this  thesis  has  by  no 
means  been  exhausted,  and  it  is  beneficial  to  consider  those  areas  to  w^hich  future 
research  might  be  directed.  A  logical  extension  to  the  muiti-ievel  model,  particularly 
in  the  light  of  namespaces,  is  the  enhancement  of  it  to  handle  encapsulated  domains  of 
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protection.  Category  sets  already  provide  a  limited  form  of  domain  structure,  Euid 
further  construction  on  top  of  this  machinery  admits  a  logicad  approach  to  the  inclu¬ 
sion  of  architecture  to  support  mutually  suspicious  cooperation  in  the  same  computa¬ 
tion. 

From  a  language  vievrpoint,  it  is  recognized  that  environment  conditioning  and 
event  handling  should  probably  be  a  unified  mechanism,  although  advantages  to  having 
them  disparate  entities  have  already  been  outlined.  Moreover,  for  exposition,  UEC  is 
more  readily  visualized  in  another  language  environment  if  it  is  considered  auto¬ 
nomous  to  the  ramifications  of  nonstandard  event  trapping  facilities.  Nonetheless,  the 
unification  of  these  mechanisms  could  be  achieved  by  reworking  the  design  of  UTRAP , 
to  incorporate  a  fail-safe  default  value  semantically  equivalent  to  the  default  of  UEC , 
This  change  to  UTRAP  is  not  upward  compatible,  but  could  be  introduced  with  proper 
consideration  of  the  concomitemt  effects  on  running  systems. 

Namespaces  appear  Logically  coinpleLe.  In  environments  other  than  APL,  the 
ancillary  access  attributes  which  partially  govern  the  behaviour  of  namespaces  should 
enforce  passnumbers  if  possible,  as  do  the  primitive  operations.  In  APL,  it  was  pointed 
out  that  the  syntax  of  the  language  does  not  easily  allow  the  provision  of  passnumbers 
on  elementary  constructs  such  as  function  cadi. 

Namespaces  properly  involve  several  peripheral  extensions  to  APL  that  have  not 
been  addressed.  The  various  nameclass  primitives  in  the  language  (llATf?,  DA^A,  5  DFr^S") 
require  modifications  to  recognize  a  namespace  as  a  new  class  of  object.  A  name 
conflict,  arising  when  two  or  more  objects  with  the  same  name  are  visible  from  the 
active  context,  must  also  be  treated  as  a  new  class. 

Since  the  models  developed  in  this  thesis  are  paper  mechanisms  only,  an 
important  direction  to  pursue  is  toward  a  protot5T>e  realization  of  the  designs  for  their 
respective  environments.  While  significant  insight  into  the  behavioural  characteristics 
of  the  mechanisms  has  been  gleaned  through  their  formal  study,  an  implementation  is 
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clearly  the  ultimate  goal  and  represents  a  primary  tool  for  increasing  our  level  of 
understanding  of  the  controls  and  for  identifying  important  issues  which  require  atten¬ 
tion.  Only  by  applying  protection  mechanisms  to  the  needs  of  real  users  can  their  ulti¬ 
mate  value,  effectiveness,  and  flexibility  be  judged. 

Much  work  remains  to  be  done  in  the  area  of  protection  mechanisms  for  com¬ 
puter  utilities.  Part  of  the  difficulty  is  that  the  design  of  machines  is  so  far  ahead  of 
the  technology  for  protecting  them,  that  it  is  a  major  issue  to  determine  what  areas  to 
regard  next.  This  thesis  has  addressed  two  specific  problems,  but  a  myriad  of  other, 
more  global  ones  remain.  The  design  and  implementation  of  protection  mechanisms 
must  become  as  methodicsd  and  as  well-understood  a  process  as  is  hardwaure  design,  so 
that  commerciad  manufacturers  of  information  processing  systems  are  encouraged  to 
provide  controls  which  limit  the  wanton  dissemination  of  information  stored  within 
such  utilities,  while  also  facilitating  desirable  forms  of  sharing  and  cooperation.  The 
paucity  of  viable,  secure  protection  mechanisms  presently  available,  and  the  rapidly 
changing  hardware  upon  which  they  run,  suggests  that  significeint  advances  have  yet  to 
be  made  before  this  goad  is  attadned. 


APPENDIX 

EXISTING  PROTECTION  FEATURES  IN  APL 


APL  presently  contains  a  number  of  features  which  were  either  designed 
specifically  as  protection  aids,  or  else  are  applicable  to  tha\,  end.  This  appendix 
discusses  these  features  briefly.  The  new  protection  controls  advocated  in  Chapter  6 
are  not  intended  to  replace  any  of  the  existing  mechanisms:  rather,  they  complement 
the  facilities  and  can  produce  some  very  desirable  results  when  used  in  conjunction 
with  them. 


A.1  Locked  Fimctions 

The  first  implementations  of  APL  included  the  notion  of  locking  functions,  as  a 
primitive  tool  for  preserving  proprietary  data.  When  a  function  is  locked,  its  definition 
becomes  immutable:  it  cannot  be  displayed:  errors  within  the  function  do  not  repro¬ 
duce  the  failing  line  of  the  program;  and  the  diagnostic  stop  (S' A)  eind  trace  (TA)  con¬ 
trols  associated  with  the  program  become  frozen.  On  systems  that  are  descendants  of 
APLSV  [Falk73],  locking  a  function  further  causes  it  to  behave  as  a  primitive:  suspen¬ 
sions  within  the  function  are  precluded,  and  errors  are  reported  at  the  line  that  called 
the  function,  rather  than  at  the  line  where  they  occurred.*  Locking  a  function  is  an 
irreversible  operation,  so  one  must  typically  retain  an  extra  copy  of  the  unlocked 
source  for  maintenance  purposes. 


•  This  stack  cut-beick  is  iterative.  If  the  invoking  line  is  also  contained  within  a  locked  function,  then  that 
level,  too,  wlU  be  cut  back.  Ihe  error  is  ultimately  reported  at  the  lowest  unlocked  lexic  level. 
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A.2  Sealed  Workspaces 

In  recognition  of  the  fact  that  the  creator  of  a  package  sometimes  requires 
the  ability  to  form  an  indispersible  environment  in  which  an  application  can  run,  sealed 
workspaces  were  introduced  into  some  implementations  of  the  language.  When  a 

workspace  is  sealed,  using  the  system  command  )SEAL,  it  is  identified  as  such  and 

\ 

becomes  subject  to  a  number  of  restrictive  attributes.  All  functions  in  the  workspace 
at  the  time  it  was  sealed  are  locked,  although  new  unlocked  functions  may  be  intro¬ 
duced  afterward:  the  erasure  of  any  locked  function  is  nilpotent;  any  )COPY  operation 
iTiio  a  sealed  workspace  behaves  as  a  protected  copy,  )PCOPY\  and  any  copy  operation 
out  of  a  sealed  workspace  ignores  functions,  if  any  were  included  within  the  scope  of 
the  command. 

The  )SEAL  command,  like  function  locking,  is  not  reversible.  This  leads  to  the 
promulgation  of  maintenance  copies  of  entire  workspaces.  Moreover,  the  apparent 
security  afforded  by  the  use  of  sealed  workspaces  is  somewhat  dubious,  since  objects 
within  a  sealed  workspace  can  still  effectively  be  erased  using  name  shadowing,  and 
then  can  be  rebound  if  desired. 

A.3  Event  Trapping 

A  number  of  APL  systems  permit  programs  to  intercept  and  recover  from  an 
error  or  an  asynchronous  interrupt.  Such  mechanisms  are  known  as  event  trapping 
facilities,  and  are  akin  to  PL/I  "ON"  conditions  (see  Weinberg  [Wein70]  and  Conway,  et 
at  [Conw77].  for  example).  Unfortunately,  no  standard  on  event  trapping  exists,  so 
most  systems  have  different  (but  comparable)  schemes  for  implementing  analogous 


features. 
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The  mechanism  described  here  is  that  of  SHARP  APL  [Iver79,  Berr79],  and  is 
somewhat  more  powerful  and  general  than  others  presently  available.  It  will  be 
explored  in  some  detail,  because  a  knowledge  of  it  is  important  for  the  discussions  on 
environment  conditioning  in  Chapter  6.  However,  the  description  should  not  be  taken 
as  an  exhaustive  treatment  of  all  of  the  mechanism’s  capabilities. 

\ 

A.3.1  Classification  and  Detection  of  Events.  The  event  trapping  facility  in  SHARP  APL 
consists  of  two  system  variables  {QTRAP  and  UER  ),  and  one  system  function  (05/C- 
NAL).  The  system  variable  UTRAP  contains  user  defined  trap  definitions,  which  let  the 
user  specify  what  events  are  to  be  detected,  and  what  is  to  be  done  when  they  ore. 

Definition.  A  trap  definition  defines  the  response  the  system  is  to  take  when  a 
particular  event  is  detected.  The  definition  consists  of  three  parts:  one  or  more 
event  numbers,  uniquely  identifying  the  events  that  the  trap  definition  is  to 
cover;  an  action  code,  specifying  how  the  definition  is  to  be  interpreted;  and  a 
trap  line,  specifying  the  latent  statement  that  is  to  be  executed  when  the  event 
occurs. 

The  first  character  of  QTRAP  is  taken  to  be  a  delimiter  which  separates  one  trap 
definition  from  another.  It  may  be  any  character  that  does  not  occur  interior  to  a 
specified  trap  definition.  Figure  A-1  shows  a  sample  trap  definition,  with  the  character 
"V”  used  as  the  delimiter. 

Events  are  assigned  numbers,  to  simplify  selecting  which  events  are  of  interest 
to  a  particular  trap  definition.  Further,  the  set  of  possible  events  is  divided  into 
classes,  so  that  an  entire  class  may  be  trapped.  For  example,  ail  errors  have  event 
numbers  between  1  and  1000,  and  may  be  collectively  trapped  using  the  number  0; 
interrupts  fall  in  the  range  1001  to  1999,  and  may  be  trapped  using  1000.  A  special 
event,  number  2001,  traps  any  return  to  immediate  execution  mode,  and  is  intended  as 
a  "last  resort"  security  feature  which  the  system  recognizes  prior  to  the  user  being 
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V  4  5  ll^C  .DAT A^ER  REDO  DATA  0  ^RESUME 


Trap  line 


'  Delimiter 


Blanks 

(around  action  code) 


Figure  A-1.  A  sample  trap  definition. 


given  control  in  the  active  environment.  User-definable  errors  are  also  permitted. 

The  event  numbers  encompassed  by  a  trap  definition  are  followed  by  a  single- 
character  action  code.  Permissible  action  codes  are  summarized  in  Table  A-l.  The 
action  code  ”D"  is  a  special  case,  and  presently  presupposes  event  3001  (the  converse 
is  also  true).  The  trap  line  for  event  2001  must  be  a  well-formed  keyword  (in  particu¬ 
lar,  "CLEAR'’  or  "EXIT")  which  can  be  interpreted,  not  executed,  and  acted  upon 
accordingly.  The  distinction  is  significant,  for  the  execution  of  a  statement  in  APL 
must  always  occur  in  some  environment,  the  precise  state  of  which  might  not  be  known 
at  the  time  an  arbitrary  event  occurs.  Hence,  an  otherwise  legitimate  recovery 
expression  might  fail  simply  because  of  the  environment  in  which  it  was  executing.  By 
contrast,  interpretation  of  a  keyword  can  proceed  independently  of  the  active 
workspace  environment,  and  is  thus  not  prone  to  the  concomitant  problems  of  state¬ 
ment  execution. 

When  an  event  occurs,  an  orderly  search  of  the  extant  trap  expressions  at  each 
level  of  the  execution  stack  is  made,  terminating  when  a  trap  definition  that  handles 
the  event  is  encountered.  The  search  is  somewhat  complex,  and  proceeds  left-to-right 
through  each  value  of  UTRAP.  working  from  the  most  local,  visible  value  downward 
through  each  shadowed  value  on  the  stack,  until  the  global  environment  is  reached. 
Since  relatively  tew  programs  localize  OTRAP  in  a  typical  application,  and  since  most 
events  tend  to  be  accepted  by  a  local  handler,  the  search  entails  much  less  work  that  it 
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TABLE  A-1.  Permissible  action  interpretations  upon  recognition  of  an  event. 


Action 

Code 

Semantics 

C 

Cut  back  stack  to  level  at  which  event  handler  was 
localized,  and  execute  specified  line  in  that  environ¬ 
ment. 

E 

Execute  specified  line  in  the  environment  m  which 
the  event  occurred  (which  may  not  be  the  environ¬ 
ment  in  which  the  handler  was  defined). 

N 

Event  is  not  trapped  at  this  level  (but  may  be  at 
another  level).  Normally  used  in  conjunction  with 
subsequent  0  or  1000  event  classes,  to  Bxclude  cer¬ 
tain  events. 

S 

Event  is  not  trapped  at  all.  Normal  system  default 
action  prevails. 

D 

Event  results  in  the  interpretation  (rather  them  the 
execution)  of  the  specified  line,  which  must  contain  a 
recognized  keyword. 

might  initially  appear  to. 


A.3.2  Event  Reporting.  The  utility  of  an  event  trapping  mectianism  iv^ould  be  limited 
were  it  not  for  the  existence  of  some  facility  to  provide  ancillary  information  about  an 
event.  The  type  of  information  that  is  required  is  precisely  what  would  have  been 
displayed  by  the  system  as  part  of  its  erstwhile  default  action,  and  includes  details 
such  as  the  event  that  occurred,  the  name  of  the  program  in  which  it  occurred,  the 
failing  program  line,  and  so  on.  When  an  event  is  detected,  this  inTormation  is 
preserved  in  the  system  variable  UER ,  where  it  may  be  used  as  part  of  a  recovery  pro¬ 
cedure.  Figure  A-2  depicts  a  sample  display  of  UER  after  a  VALUE  ERROR  on  line  3  of 
the  program  REPORT.  UER  also  contains  the  event  number  (8  in  this  case),  so  that  a 
program  may  interpret  the  contents  of  the  variable  more  readily  than  by  examining 
the  spelling  of  the  name  of  the  event.  The  diagnostic  information  is  airranged  as  a 
three-row  matrix,  to  facilitate  extracting  selected  information  from  it. 
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Event 

no.  Space  Ev^t  title 

ERROR 

RERORTl2'\  DISRLAY^ITEMS  BESIDE  TOTAL 

y  ^  ^  ■■  V  ■■!  - ' 


Fn.  name 

&  line  no.  Statement  being  executed 


Caret  points  where  system  was  working 


Figure  A-2.  A  sample  event  report  display. 


A.3.3  Signalling  User-Instigated  Events.  The  system  function  DSIGNAL  allows  a  user- 
defined  function  to  generate  a  signal  that  a  particular  event  has  occurred-  The  event  is 
reported  at  the  nest  lower  level  of  the  execution  stack  (the  level  at  which  the  function 
was  called),  and  may  be  trapped  in  the  same  way  as  system-generated  errors.  □S’/C- 
NAL  therefore  makes  it  possible  for  a  defined  function  to  report  events  in  a  manner 
similar  to  a  primitive  function.  The  output  in  Figure  A-3  illualrates  a  typical  example, 
and  shows  how  the  reporting  might  appear. 

USIGNAL  is  a  divalent  system  function.  The  left  argument  is  optional,  but  if 
present  must  be  a  character  vector  which  is  used  as  the  text  of  the  event  message  for 
display  on  the  terminal  and  for  HER.  If  the  left  argument  is  elided  (as  in  Figure  A-3), 
the  default  system  event  name  is  used. 


A.4  Shared  Variables 

Shared  variables  [Falk73,  Lath73]  is  an  APL  feature  which  wais  designed  to 
permit  controlled  communication  between  independent,  concurrently-executing 
processes.  The  mechanism  was  not  specifically  introduced  as  a  tool  to  aid  in  writing 
secure  software,  but  can  be  employed  for  this  purpose  with  a  small  amount  of  addi- 


-  150  - 


V  Z^A  PLUS  BiUTRAP 

[1]  UTRAP^^  o  0  E  USIGNAL  t^^pUER^ 

[2]  Z^A+B 


7 


2  PLUS  MSC 


2+MSC’ 


DOMAIN  ERROR 


DOMAIN  ERROR 


2  PLUS  MBC" 


2+M5^:» 

A  ' 


A 


1  2  PLUS  234 


12  +  234 


LENGTH  ERROR 


LENGTH  ERROR 

12  +  234 


1  2  PLBB  234 


A 


A 


Figure  A-3.  Signalling  events  from  defined  functions. 


tioned  complication.  The  architecture  which,  results  is  similar  to  Lampson's  message 
system  [Lamp71],  which  he  described  in  the  context  of  operating  systems. 

Two  autonomous  processes  communicate  using  shared  variables  by  establishing 
a  sharing  bond  between  them.  To  do  this,  either  process  offers  the  name  of  a  VEiriable 
to  the  other.  The  second  process  then  completes  the  coupling  bond  by  making  a 
counter  offer.  In  order  to  provide  synchronous  control  (both  full  and  half  duplex)  of 
the  communication  channel,  an  access  control  vector  can  be  set  at  each  end  of  the 
sharing  bond.  The  vector  determines  the  order  in  which  each  process  can  reference 
and  set  the  value  of  the  shared  variable.  Both  processes  have  equal  (but  reflected)  say 
in  the  setting  of  the  access  control  vector;  the  effective  control  vector  is  the  logical 
"or"  of  the  two  vectors  specified  by  the  participating  processes. 

The  use  of  shared  variables  as  a  protection  mechanism  offers  a  number  of 
salient  advantages.  The  physical  separation  of  the  tasks  ensures  completely  private 
environments,  the  only  accessible  objects  being  those  which  both  tasks  have  mutually 
agreed  to  share.  The  user  can  read  and  write  only  a  program’s  shared  variables,  euid 
even  then  only  when  permitted  to  do  so  by  the  access  control  vector.  In  addition,  the 
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mechanism  is  capable  of  supporting  separable  combinability,  simply  by  sharing  vari¬ 
ables  with  more  than  one  package  at  once.  Nested  combinability  can  be  achieved  by 
having  one  package  share  variables  with  another.  Separable  nesting  is  also  easily  pos¬ 
sible.  In  fact,  any  arbitrary  graph  of  sharing  bonds  can  be  established. 

Like  Lampson’s  message  system,  however,  using  shared  variables  for  protection 
is  logically  complete,  but  somewhat  inefiflcient.  Too  elaborate  a  setup  is  required  to  get 
processes  to  cooperate.  The  root  of  the  problem  lies  with  the  fact  that  shared  vari¬ 
ables  was  designed  to  provide  communication  facilities  between  concurrent  processes; 
protection  mechanisms  are  inherently  sequentuil,  because  they  are  dedicated  to  a  par¬ 
ticular  task.  Further,  additional  overhead  and  an  additional  level  of  complexity  is 
incurred  by  having  to  maintain  an  auxiliary  processor  capable  of  acting  as  a  general 
shared  variable  server :  for  a  particular  sensitive  package.  A  proliferation  of  such 
servers  would  also  result  as  the  number  of  application  packages  increased.  Thus,  while 
shared  variables  exhibits  many  of  the  desirable  features  of  a  protection  mechanism,  it 
is  in  practice  somewhat  cumbersome  and  inappropriate. 
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CSRG-95  PISA:  A  PROGRAMMING  SYSTEM  FOR  INTERACTIVE 
PRODUCTION  OF  APPLICATION  SOFTWARE 
Rudolf  Marty,  August  1970 

CSRG-96  ADAPTIVE  MICROPROGRAMMING  AND  PROCESSOR  MODELING 
YiTalter  G.  Rosocha 
[Ph.D.  Thesis.  EE.  August  1973] 

*  CSRG-97  DESIGN  ISSUES  IN  THE  FOUNDATION  OF  A  COMPUTER-BASED 

TOOL  FOR  MUSIC  COMPOSITION 
William  Buxton 

(M.Srv  Thrra?!,  ('ISRG.  0(d,f>l>f'r  1978] 
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CSRG-98  THEORY  OF  DATABASE  MAPPINGS 
Anthony  C,  King 

[Ph.D.  Thesis.  DCS,  December  1973] 


CSRG-99  HIERARCHICAL  COROUTINES:  A  MECHANISM  FOR  IMPROVED 
PROGRAM  STRUCTURE 
Leonard  1.  Vanek.  February  1979 


CSRG-lUO 


TOPICS  IN  PERFORMANCE  EVALUATION 
G.  Scott,  Graham  (erL),  July  1979 


*  CSRG-101  A  PANACHE  OF  DBMS  IDEAS  II 

F.H.  Lochovsky  (ed.),  May  1979 


CSRG-102  A  SIMPLE  SET  THEORY  FOR  COMPUTING  SCIENCE 
Eric  C.R.  Hehner,  May  1979 


CSRG-103  THE  CENTRALIZED  ALGORITHM  IN  DISTRIBUTED  SYSTEMS 
Ernest  J.H.  Chang 
[Ph.D.  Thesis,  DCS,  July  1979] 

CSRG-104  ELIMINATING  THE  VARIABLE  FROM  DIJKSTRA’S 
MINI-LANGUAGE 
D.  Hugh  Redelmeier,  July  1979 


CSRG-105  A  LANGUAGE  FACILITY  FOR  DESIGNING  INTERACTIVE 
DATABASE-INTENSIVE  APPLICATIONS 
John  Mylopoulos.  Philip  A.  Bernstein,  Harry  K.T.  Wong, 
July  1979 

CSRG-106  ON  APPROXIMATE  SOLUTION  TECHNIQUES  FOR 

QUEUEING  NETWORK  MODELS  OF  COMPUTER  SYSTEMS 
Satish  Kumar  Tripathi,  July  1979 


CSRG-107  A  FRAMEWORK  FOR  VISUAL  MOTION  UNDERSTANDING 
John  K.  Tsotsos,  John  Mylopoulos,  H.  Dominic  Covvey 
Steven  W.  Zucker,  DCS,  June  1979 


*  CSRG-103  DIALOGUE  ORGANIZATION  AND  STRUCTURE  FOR 

INTERACTIVE  INFORMATION  SYSTEMS 
John  Leonard  Barron 
[M.Sc.  Thc'Jis,  DCS,  1980] 

*  CSRG-109  A  UNIFYING  MODEL  OF  PHYSICAL  DATABASES 

D.S.  Batory,  C.C.  Gotlieb,  April  1980 

*  CSRG-110  OPTIMAL  FILE  DESIGNS  AND  REORGANIZATION  POINTS 

D.S.  Batory,  April  1980 

*  CSRG-1 1 1  A  PANACHE  OF  DBMS  IDEAS  III 

D.  Ti^ichi  it/is  (ccl.),  April  1980 
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CSRG-112  TOPICS  IN  PSN  -  II:  EXCEPTIONAL  CONDITION 

HANDLING  IN  PSN:  REPRESENTING  PROGRAMS  IN  PSN: 

CONTENTS  IN  PSN 

Yves  Lesperance,  Byran  M.  Kramer,  Peter  F.  Schneider 
April,  19B0 

CSRC-113  SYSTEM-ORIENTED  MACRO-SCHEDULING 
C.C.  Gotlieb  and  A.  Schonbach 
May  1980 

CSRG-1 14  A  FRAMEWORK  FOR  VISUAL  MOTION  UNDERSTANDING' 

John  Konstantin©  Tsotsos 
[Ph.D.  Thesis.  DCS,  June  1980] 

CSRG-1 15  SPECIFICATION  OF  CONCURRENT  EUCUD 
James  R.  Cordy  and  Richard  C.  Holt 
July  1980 

CSRG-1 16  THE  REPRESENTATION  OF  PROGRAMS  IN  THE 

PROCEDURAL  SEMANTIC  NETWORK  FORilALISM 

Bryan  M.  Kramer 

[M.Sc.  Thesis.  DCS,  1980] 

CSRCt-117  CONTEXT-FREE  GRAMMARS  AND  DERIVATION  TREES  AS 
PROGRAIvlMING  TOOLS 
Volker  Linnemann 
September  1980 

CSRG-1 18  S/SL:  SYNTAX/SEMANTIC  LANGUAGE 
INTRODUCTION  AND  SPECIFICATION 
RC.  Holt,  J.R.  Cordy.  D.D.  Wortman 
CSRG,  September  1960 

CSRG-1 19  PT:  A  PASCAL  SUBSET 
Alan  Rosselet 

[M.Sc.  Thesis,  DCS,  October  19B0] 

CSRG-120  PTED:  A  STANDARD  PASCAL  TEXT  EDITOR  BASED  ON 
THE  KTIRNIGHAN  AND  PLAUGER  DESIGN 

Ken  Newman.  DCS 
October  1980 

CSRG-121  TERMINAL  CONTEXT  GRAMMARS 
Hov.'ard  W.  Trickey 
[M.Sc.  Thesis,  EE,  September  1980] 

CSRG- 122  THE  APPROXIMATE  SOLUTION  OP  LARGE  QUEUEING 
NETWORK  MODELS 
John  Z ah  or  j  an 

[Ph.D.  Thesis,  DCS,  August  1980] 
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CSRG-123  A  FORMAL  TREATMENT  OF  IMPERFECT  INFORMATION 
iN  DATABASE  M/VNAGEMENT 
Yannis  Vassiliou 

[Ph.D.  Thesis,  DCS,  September  19S0j 

CSRG-124  AN  ANALYTIC  MODEL  OF  PrtY'SICAL  DATABASES 
Don  S.  Batory 

[Ph.D.  Thesis,  DCS.  o^anuary  19tilj 


CSRG-125  MACHINE-INDEPENDENT  CODE  GEN'EKATKJN 


Richard  K.  Kozlak 

[M.Sc.  Thesis,  DCS,  January  1931] 


CSRG-1E6  COMPUTER  MACRO-SCHEDULING  FOR  HIGH  PRODUCTIVITY 
Abraham  Sehonbach 
[Ph.D.  Thesis.  DCS,  March  1901] 


CSRG-127  OMEGA  ALPHA 

D.  Tsichritzis  (ed.),  March  1931 

CSRG-128  DIALOGUE  AND  PROCESS  DESIGN  FOR  INTERACTIVE 
INFORMATION  SYSTEMS  USING  TAXIS 
John  Bai'ron,  April  1901 

CSRG-129  DESIGN  AND  VERIFICATION  OF  INTERACTIVE  INFORMATION 
SYSTEMS  USING  TAXIS 
Harry  K.T.  V>ong 

[Ph.D.  Thesis.  DCS.  to  be  submitted] 

CSRG-130  D^'NAMIC  PROTECTION  OF  OBJECTS  IN  A  COMPUTER  UTILITY 
Leslie  H.  Goldsmith.  A.prii.  1931 


